密封类将继承控制从运行时提前至编译期，通过 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，终于有了确定性的收口能力。