sealed 修饰类：阻止继承，编译期就报错
加了
sealed的类，别人一写
class B : A就直接编译失败，错误信息是：
'B' cannot inherit from sealed class 'A'。这不是运行时检查，而是编译器提前拦截，完全杜绝派生可能。 适用场景：工具类（如
JsonSerializer封装）、敏感逻辑类（如密码哈希器）、值对象（
UserIdentity）——你不想让任何人通过继承绕过校验或篡改行为 性能影响：JIT 编译器对
sealed类的虚方法调用可做去虚拟化（devirtualization），调用更快；反射查找成员也略快（因无需遍历继承链） 常见误用：和
abstract同时出现 → 编译错误，二者语义冲突（一个强制被继承，一个禁止被继承）
sealed 修饰方法：必须配合 override，只封“这一层”的重写权
sealed不能单独用于方法，它必须和
override成对出现，作用是：允许子类继承当前类，但禁止子类再重写这个已被密封的方法。
public class A
{
public virtual void DoWork() => Console.WriteLine("A");
}
public class B : A
{
public sealed override void DoWork() => Console.WriteLine("B (sealed)");
}
public class C : B
{
// ❌ 编译错误：'C.DoWork()' cannot override inherited member 'B.DoWork()' because it is sealed
// public override void DoWork() => Console.WriteLine("C");
}
典型用途：在框架基类中开放部分可定制点，但关键流程节点（如 ValidateInput()、
EncryptPayload()）必须由你控制实现，不许下游覆盖 注意：密封的是“重写行为”，不是“调用权限”——
C仍能调用
B.DoWork()，只是不能改它 如果父类方法没声明
virtual或
abstract，子类里用
new隐藏它，那根本不需要、也不能加
sealed
为什么 string、DateTime 是 sealed 的？这不只是“设计选择”
.NET 基础类型大量使用
sealed，不是为了“炫技”，而是防止破坏契约：
string密封 → 避免有人继承后偷偷改
Length或
==行为，导致 LINQ、JSON 序列化等底层逻辑出错
DateTime密封 → 确保其不可变性（immutability）不被子类通过重写
AddDays()等方法破坏 结构体（
struct）默认就是隐式
sealed，所以你连写
sealed struct S { } 都会报错
容易被忽略的细节：sealed 不等于 private，也不影响接口实现
sealed只管“能不能被继承”，不管“能不能被访问”或“能不能实现接口”： 一个
public sealed class Logger : ILogger完全合法 —— 外部代码可以 new 它、调用它、传给依赖
ILogger的方法，只是不能从它派生
sealed类里的成员访问修饰符照常生效：
private sealed void Helper()是语法错误（
sealed不能修饰成员方法，只能修饰类或
override方法） 别指望靠
sealed防止反序列化构造实例 ——
JsonSerializer.Deserialize<sealedclass>()</sealedclass>依然可行，它不走
new，而是绕过构造函数直接填充字段 sealed 的真正价值不在“锁死代码”，而在明确传达设计意图：这里不欢迎定制，请按契约使用。一旦滥用，比如把本该扩展的策略类提前密封，后续维护时就得重构接口或引入委托回调——比继承还难懂。
