sealed类仅在对其实例调用虚方法时触发JIT内联优化，因跳过vtable查找；若无虚方法调用或方法非虚，则无性能提升。
sealed 类能触发 JIT 内联优化，但只在虚方法调用路径上生效
不是所有 sealed 类都会变快，关键看它有没有被当作基类、有没有虚方法被调用。CLR（.NET 运行时）真正能加速的，是「对密封类实例调用虚方法」这一场景：因为编译器/运行时 100% 确定该方法不会被重写，于是可跳过虚方法表（vtable）查找，直接生成内联或直接调用指令。
常见误判：sealed 类里全是静态方法、或只调用非虚成员（如 private / static / sealed override 方法），那加不加 sealed 对性能几乎没影响。
- ✅ 有效加速场景：频繁调用
ToString()、GetHashCode()或自定义virtual方法，且该类已标记sealed - ❌ 无效场景：类只有
static工具方法；或实例方法全为private/internal且未被继承链涉及 - ⚠️ 注意：JIT 是否实际内联，还取决于方法体大小、调用频率、.NET 版本（如 .NET 6+ 内联策略更激进）
CS0509 编译错误是第一道防线，但它和性能无关
当你写 class Sub : Payment { } 而 Payment 是 sealed，编译器立刻报错 CS0509：“无法从密封类派生”。这纯属设计约束，和运行时性能毫无关系——它发生在编译期，不参与 JIT 优化决策。
但这个错误间接提升了稳定性，从而减少“因意外继承导致的逻辑绕过”，比如：
- 子类重写
Pay()却漏掉风控校验 → 生产扣款异常 - 测试时 Mock 不了
sealed类 → 强制你改用接口或委托，反而推动更松耦合设计
String 类为什么 sealed？不是为快，而是为不可变语义兜底
string 是 .NET 中最著名的 sealed 类，但它性能优势的根源不在 sealed，而在其底层实现（如字符串驻留、不可变性保障）。sealed 在这里是“必要不充分条件”：防止子类篡改 Length、this[] 或内部字符数组引用，从而守住整个字符串模型的安全边界。
换句话说：没有 sealed，string 的不可变契约就可能被打破；但加了 sealed，也不代表所有字符串操作都自动变快。
- 高频拼接仍推荐
StringBuilder，和sealed无关 -
string.IsNullOrEmpty()快，是因为它被 JIT 特别优化 + 非虚调用，不是单纯靠sealed
别为了“理论上更快”而滥用 sealed，真实瓶颈往往不在这里
在微服务或 Web API 场景中，一个 sealed 类带来的调用开销降低，通常远小于一次 HTTP 解析、数据库 round-trip 或 JSON 序列化耗时。盲目加 sealed 可能反伤可测性——比如 Moq 无法继承 mock，逼你补接口或改构造注入方式。
真正值得加 sealed 的地方，优先级应该是：
- 核心领域模型（如
Money、OrderId）→ 防止状态被子类污染 - 封装硬件/第三方 SDK 的驱动类（如
PrinterDriver）→ 避免用户继承后误调底层 C API - 明确无扩展需求的工具类（如
JsonHelper）→ 减少 IDE 提示“可继承”的干扰
性能提升只是副产品，不是设计动机；一旦你开始为每层 DTO 都加 sealed，大概率是在优化错误的地方。
