sealed修饰类可阻止继承，编译期报错；修饰方法需配合override，仅禁止进一步重写；用于工具类、敏感逻辑、值对象等场景，提升性能并明确设计意图。
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>()依然可行，它不走new，而是绕过构造函数直接填充字段
