在C#的类设计中，继承是一把双刃剑。它带来了代码复用的便利，但也可能让类的行为被无意中修改，埋下难以排查的隐患。比如你精心设计的一个工具类，被同事继承后重写了某个关键方法，结果整个系统的行为都变了。为了解决这类问题，C#提供了sealed关键字，它可以阻止类被继承，也可以阻止虚方法再次被重写。这篇文章就来详细聊聊sealed的用法、原理和实际应用场景。
sealed修饰类：让类彻底失去被继承的能力
当sealed关键字直接用在class声明上时，这个类就成了密封类。任何代码尝试从密封类派生子类，编译器都会直接报错。这一点和abstract正好相反：抽象类只能被继承不能被实例化，而密封类只能被实例化不能被继承。
看一个最简单的例子：
public sealed class PaymentService
{
public void ProcessPayment(decimal amount)
{
Console.WriteLine($"处理支付金额：{amount}");
}
}
// 下面这行代码无法编译通过
// public class AlipayService : PaymentService { }
编译器会给出明确的错误提示：无法从密封类型派生。这种保护是在编译期完成的，也就是说只要项目能编译通过，就不用担心这个类被谁继承了。
那么什么样的类适合标记为sealed呢？一般来说有三类。第一类是工具类和帮助类，比如字符串处理、日期格式化这类没有扩展意义的类，代表就是.NET自带的String类，它就是密封的。第二类是包含安全敏感逻辑的类，例如权限校验、加密解密相关的实现，一旦被继承重写就可能被绕过。第三类是不可变类型，继承并重写成员可能破坏其不可变性保证。另外在框架开发中，如果某个扩展点不打算对外开放，也应该用sealed明确关闭。
sealed修饰方法：终结继承链上的重写
密封类的用法比较直观，但sealed用在方法上时就有讲究了。首先必须明确一点：sealed不能单独修饰方法，它必须和override搭配使用。也就是说，只有重写了基类虚方法的方法，才有资格被密封。语法形式是sealed override。
它的含义是：这个方法重写了基类的实现，但到此为止，后续的派生类不允许再继续重写它。这相当于在继承链的某一环上把重写通道关闭了。
public class Animal
{
public virtual void MakeSound()
{
Console.WriteLine("动物发出声音");
}
}
public class Dog : Animal
{
// 重写并密封：Dog以下的派生类不能再重写MakeSound
public sealed override void MakeSound()
{
Console.WriteLine("汪汪");
}
}
public class Puppy : Dog
{
// 下面这行会编译报错
// public override void MakeSound() { }
}
注意上面代码中的Puppy类本身是可以正常存在的，它只是不能重写MakeSound方法而已。这一点初学者容易搞混：密封的是方法，不是类。Puppy仍然可以新增自己的成员，也可以重写Animal中其他未被密封的虚方法。
这种设计在实际开发中很实用。假设基类定义了五个虚方法，中间某个类重写了其中两个并希望这两个的实现固定下来，不被更下层的子类改动，就可以只对这两个方法加sealed，其余三个保持开放。控制粒度比直接密封整个类更细。
sealed与abstract、static的组合规则和常见误区
sealed虽然好用，但它和其他修饰符的组合有不少限制，用错了编译器不会给你好脸色。最基本的一条：sealed和abstract不能同时使用。因为abstract意味着必须被继承才有意义，而sealed禁止继承，两者自相矛盾。同理，sealed和static也不能共存，因为静态类本身就不存在继承的概念，加sealed毫无意义。此外抽象类中的抽象成员也不能被密封，理由同上。
还有一个容易踩的坑：sealed不能修饰非虚方法。比如基类有个普通public方法，子类想用sealed标记它是不行的，编译器会报错。因为普通方法本来就不存在重写的可能，密封它没有意义。如果想阻止子类隐藏父类方法，那需要的是别的手段，比如把方法标记为非虚并避免使用new关键字隐藏。
下面这张表总结了常见修饰符组合的合法性：
| 组合方式 | 是否合法 | 说明 |
|---|---|---|
| sealed class | 合法 | 密封类，禁止被继承 |
| sealed override 方法 | 合法 | 密封已重写的虚方法 |
| abstract sealed class | 不合法 | 语义冲突 |
| static sealed class | 不合法 | 静态类无需密封 |
| sealed 普通方法 | 不合法 | 非虚方法不存在重写 |
密封带来的性能收益与设计取舍
除了安全性和设计约束之外，sealed还有一个经常被忽略的好处：性能。当JIT编译器知道一个类是密封的，它就能确定该类不存在任何派生类，虚方法调用时无需去查虚方法表，可以直接采用更激进的内联优化。这种优化在高频调用场景下能带来可观的提升。正因如此，不少性能敏感的类库（包括.NET Core中的许多内部类型）都倾向于将不需要扩展的类标记为sealed。
当然，性能收益通常不是选择密封的首要理由，设计意图才是。是否使用sealed，本质上是在回答一个设计问题：这个类的未来扩展点在哪里？如果答案是明确的“不需要扩展”，那就大方地密封它。这样做还有一个附带好处：当你日后想开放继承时，去掉sealed是向后兼容的改动；反过来，先开放后密封则是破坏性变更，会让现有的派生类全部编译失败。所以稳妥的策略是：默认密封，确有扩展需求时再开放。这和很多框架提倡的“设计为不可扩展，直到被证明需要扩展”的思路是一致的。
总结一下，sealed关键字在C#中承担着关闭继承通道的职责：用在类上，类不可被继承；配合override用在方法上，方法不可再被后续派生类重写。合理使用它，既能让设计意图更清晰，也能守住代码的安全边界，顺带还能获得一点性能上的免费午餐。