密封类将继承控制从运行时提前至编译期，通过 sealed + permits 显式限定直接子类，确保穷尽性检查、统一测试与契约保障，且仅对自身可修改的代码生效。
密封类把“谁能继承我”从运行时问题变成编译期错误
它不靠文档警告、不靠代码审查，而是用 sealed + permits 组合让非法继承在 javac 阶段就失败。比如你定义了 public sealed interface Result permits Success, Error，第三方在自己包里写 class HackResult implements Result，直接编译报错：「not allowed to extend sealed interface」。
这和传统 final 不同：final 是彻底封死，sealed 是“只开几扇门”，既可控又留有组合空间。
- 模块边界也能控制：在
module-info.java中配合opens或exports，可限制跨模块的permits列表可见性 - 反射也绕不过去：JVM 类加载器会在
defineClass阶段校验继承关系，动态生成子类会抛IncompatibleClassChangeError - IDE 和构建工具（如 Maven 编译插件）能立刻感知变更，避免“本地能跑、CI 报错”的割裂
为什么 permits 必须显式列出所有直接子类
因为这是穷尽性检查的前提。编译器只有知道全部可能分支，才能在 switch (r) 中确认你没漏掉 case Warning —— 如果允许隐式扩展，这个保障就崩了。
注意：每个 permits 列出的类还必须带明确修饰符：
-
final：终端节点，不可再继承（适合数据载体，如record Success(String data)） -
sealed：可继续向下密封（适合分层建模，如sealed class Event permits UserEvent, SystemEvent） -
non-sealed：主动打开继承链（慎用，等于局部放弃控制，仅在极少数需兼容旧扩展点时考虑）
漏写修饰符？javac 直接报错，不给你蒙混过关的机会。
密封类不是为“防用户”，而是为“保契约”
开放接口常被第三方实现，但没人能约束他们怎么重写 toString()、是否在 equals() 里引入非对称逻辑、或让 area() 返回负数。这些行为漂移不会导致编译失败，却会让调用方在运行时崩溃。
而所有 permits 子类都在你的源码树/模块内，意味着：
- 可统一做单元测试覆盖边界值（比如所有
area()实现都测过零输入、负输入） - 序列化/反序列化逻辑可集中管控，不用到处写
instanceof防御性判断 - 协议升级时，新增一个
Timeout子类？必须改permits列表 → 强制触发 code review 和兼容性评估
容易被忽略的硬性约束：子类必须与密封父类在同一个编译单元
Java 要求所有 permits 子类必须和密封类/接口在同一个模块（或默认模块下同一 package），不能跨模块声明许可——除非你在 module-info.java 中显式用 opens 或 exports 开放该 package 并配合同步许可。
这意味着：你无法用密封机制“假装”控制外部库的类型。它只对你能修改的代码生效。想靠 sealed 封住别人写的框架？做不到。它的价值恰恰在于：你对自己发布的 API，终于有了确定性的收口能力。
