1. 从一行报错说起：为什么重写Label控件时属性会“失灵”
很多做C#桌面开发的朋友，第一次尝试自定义控件时，都会遇到一个很典型的场景：想给Label加个背景渐变、加个边框、或者让文字垂直居中，于是新建一个类继承自Label，然后兴冲冲地去重写OnPaint。结果发现，要么背景色怎么设都不生效，要么父容器的背景色透不过来，要么设计器里改属性完全没反应。
这个问题的根子，往往不在OnPaint本身，而在于对虚拟属性（virtual）和抽象属性（abstract）的重写机制理解得不够透。Label这个控件在.NET的控件体系里位置很特殊——它继承自Control，但又在Control的基础上把很多属性标记成了virtual，允许子类去改变行为。如果你只是简单地new一个属性把父类的盖掉，那叫隐藏（hiding），不是重写（overriding），多态调用的时候走的还是父类的实现，你的代码自然不生效。
我见过太多项目里，有人写了个MyLabel，里面用new关键字重新声明了Text属性，然后在窗体里用Label类型的变量去引用它，结果拿到的还是基类的Text。这种坑不踩一次很难记住。所以这篇内容，我打算把C#里虚拟属性和抽象属性的重写机制，结合Label实例的完整改造过程，从头到尾捋一遍。不管你是刚接触C#继承体系的新手，还是写过一些自定义控件但总觉得“哪里不对劲”的老手，应该都能从中找到自己需要的那块拼图。
整篇内容会围绕一个实际可运行的GradientLabel展开，从属性重写的底层逻辑讲起，再到Label自身哪些属性可以重写、哪些不能，然后是完整的绘制改造、设计器适配、性能注意事项，最后聊几个我实际项目中踩过的坑。代码全部可复制运行，环境是.NET Framework 4.7.2和.NET 6的WinForms都验证过。
2. virtual和abstract在属性上的本质区别：不只是“能不能有实现”
2.1 从IL层面看两者的分派机制
要理解属性重写，得先明白C#里属性本质上就是方法。一个属性public string Text { get; set; }编译之后会变成get_Text()和set_Text()两个方法。所以属性能不能重写，取决于这两个访问器方法是不是虚拟的。
virtual关键字告诉编译器：这个方法有一个默认实现，但子类可以用override提供自己的版本。运行时通过**虚方法表（vtable）**来分派——变量声明类型是父类，但实际对象是子类时，调用的是子类重写后的版本。这就是多态的基础。
abstract则更严格：它只声明签名，不提供任何实现，而且必须放在抽象类里。子类必须用override实现它，否则子类也得是抽象的。从IL角度看，抽象方法在vtable里占了一个槽位，但没有对应的方法体，运行时如果调用到一个没被实现的抽象方法，会抛NullReferenceException或者更准确的TypeLoadException。
放到属性场景里，区别就很直观了：
| 特性 | virtual属性 | abstract属性 |
|---|---|---|
| 是否有默认实现 | 有 | 无 |
| 所在类是否必须抽象 | 否 | 是 |
| 子类是否必须重写 | 否 | 是 |
| 能否直接实例化所在类 | 能 | 不能 |
| 典型用途 | 提供可扩展的默认行为 | 强制子类定义契约 |
Label里的属性绝大多数是virtual而非abstract，因为Label本身要能直接实例化使用。比如Text、Font、ForeColor、BackColor这些，都是virtual的，你可以重写，也可以不重写。
2.2 一个容易混淆的点：重写属性时访问器的选择性
重写一个属性时，你不必把get和set都重写。比如父类定义了public virtual string Text { get; set; }，子类可以只重写get：
public override string Text { get { return base.Text + " (已处理)"; } // 不重写set，继承父类的set行为 }但这里有个限制：如果父类的属性只有get没有set，子类重写时不能凭空加一个set。反过来，父类有get和set，子类只重写get是合法的，set会自动继承父类的实现。这个规则在改造Label时很有用——比如你只想在读取Text时做点转换，写入时保持原样，就可以只重写get。
还有一个细节：base.Text在重写的get里调用的是父类的get实现，不会造成递归。这是C#里访问基类成员的标准方式，和base.OnPaint是一个道理。
2.3 为什么new关键字是个陷阱
很多人分不清override和new。new是隐藏基类成员，它创建一个全新的成员，和基类那个没有多态关系。看这段代码：
public class BaseLabel : Label { public new virtual string Text { get { return "Base版本"; } } } public class DerivedLabel : BaseLabel { public override string Text { get { return "Derived版本"; } } } // 使用 Label lbl = new DerivedLabel(); Console.WriteLine(lbl.Text); // 输出什么？答案是Base版本。因为lbl的声明类型是Label，Label.Text这个槽位在BaseLabel里被new隐藏了，DerivedLabel重写的是BaseLabel新引入的那个Text，而不是Label原本的Text。多态分派走的是Label的vtable槽位，那里还是Label自己的实现。
这个坑在自定义控件里特别隐蔽，因为设计器生成的代码通常用基类类型声明变量。所以记住一条铁律：要改变多态行为，必须用override，绝不能用new。new只在你确实想切断继承链、另起炉灶时才用，那种场景极少。
3. Label控件里哪些属性值得重写，哪些碰不得
3.1 可以安全重写的属性清单
Label继承自Control，一路往上还有Component和MarshalByRefObject。在这个继承链上，被标记为virtual的属性不少，但真正适合在自定义Label里重写的，主要集中在和绘制、布局、文本相关的部分。
我整理了一份实际项目中常用的可重写属性：
- Text：最常重写的属性。可以用来做文本格式化、加前后缀、做敏感词过滤显示等。重写get时注意不要在里面做耗时操作，因为设计器和运行时都会频繁读取。
- Font：可以重写get返回一个缩放后的字体，实现自动适配DPI的效果。但要注意字体对象的创建开销，最好缓存。
- ForeColor / BackColor：重写这两个可以实现主题色自动切换。不过
Label默认的BackColor是Transparent，重写时要小心处理透明逻辑。 - AutoSize：重写get可以强制控件始终自动调整大小，避免设计器里被手动改乱。
- DefaultSize：这是
protected virtual的，重写它可以改变控件拖到窗体上时的初始尺寸。 - TextAlign：重写get可以强制文本对齐方式，比如始终居中。
- OnPaint / OnPaintBackground：虽然不是属性，但和属性重写配合使用，是自定义绘制的核心。
这些属性的共同点是：它们要么影响外观，要么影响布局，重写后能直接改变控件的表现，而且不会破坏Label的内部状态机。
3.2 不建议重写的属性及原因
有些属性虽然也是virtual的，但重写它们风险很高。比如Bounds、Location、Size这些布局属性，Label内部和父容器的布局引擎有复杂的交互，你重写get返回一个假值，可能导致布局计算错乱、控件闪烁甚至死循环。
还有Enabled、Visible这类状态属性，重写它们会干扰Control基类的状态管理逻辑。比如你重写Visible的get返回false，但内部状态还是true，绘制和命中测试就会不一致。
Parent、Site这些和容器、设计器相关的属性更是碰不得，重写它们基本等于自毁。
我的经验是：只重写那些“纯数据”或“纯表现”的属性，不碰任何涉及控件生命周期和布局引擎的属性。判断标准很简单——如果这个属性的值改变会触发Control基类里的一系列内部方法调用（比如OnSizeChanged、OnVisibleChanged），那就别重写。
3.3 抽象属性在自定义控件体系中的定位
Label本身没有抽象属性，因为它不是抽象类。但如果你在做一个控件库，定义了一个抽象基类比如BaseChartControl，里面就可以用抽象属性来强制子类提供关键数据。比如：
public abstract class BaseChartControl : Control { public abstract double[] DataPoints { get; } public abstract Color SeriesColor { get; set; } }这样任何继承BaseChartControl的图表控件，都必须实现这两个属性，否则编译不过。抽象属性的价值在于契约强制——它把“子类必须提供什么”写进了类型系统，而不是靠文档或口头约定。
在实际项目里，抽象属性用得比抽象方法少，因为属性往往需要配套的变更通知逻辑。如果子类实现抽象属性时忘了触发Invalidate，图表就不会重绘。所以更稳妥的做法是：抽象基类里定义一个protected abstract double[] GetDataPoints()方法，然后在一个非抽象的DataPoints属性里调用它并处理通知。这样既强制了子类实现，又统一了通知逻辑。
4. 动手改造一个GradientLabel：从属性重写到绘制落地
4.1 项目结构与基础类搭建
我们来做一
