密封类需正确使用sealed+permits，子类须同包/模块、显式声明final/sealed/non-sealed，漏写或错配导致编译失败，且non-sealed会破坏密封性。

直接用 sealed + permits 就能拦住非法子类，但关键不是“写了就安全”，而是写对位置、配对修饰符、守住包/模块边界——否则编译器根本不会校验。

密封类必须显式列出所有直接子类

Java 17 不允许省略 permits 子句（Java 21+ 才支持自动推导）。漏写一个子类，或拼错类名，编译直接失败。

• permits 后的类名必须与实际子类的全限定名一致（包括大小写），且不能是内部类或匿名类
• 所有被 permits 列出的子类必须与密封类在同一个包（非模块化项目）或同一模块（模块化项目）中
• 如果子类在另一个包里，即使加了 public，也会报错：error: class X is not allowed to extend sealed class Y

每个被许可子类必须声明 final/sealed/non-sealed

子类不加这三者之一，编译器拒绝通过。这不是可选约定，是语法硬性要求。

• final：最常用，彻底终止继承链，适合状态固定、不可变的领域类型（如 Pending、Delivered）
• sealed：子类自己也想控制继承，比如 PaymentMethod 下再分 CreditCard 和 PayPal，就得继续密封
• non-sealed：只应在明确需要开放扩展的分支使用（如框架插件点），但一旦用了，该分支就完全脱离密封体系，后续子类不再受任何限制

模式匹配时依赖密封性做穷尽检查

密封类真正发挥价值的地方，是在 switch 表达式中省掉 default 分支——前提是编译器确认你已覆盖所有可能子类型。

• 若某子类被误标为 non-sealed，而你又在 switch 里只写了已知子类，编译器仍会报错：the switch expression does not cover all possible values
• 只有所有 permits 子类都声明为 final 或 sealed（且其子类也最终收敛），编译器才能认定类型穷尽
• 记录类（record）和密封类配合最自然，字段自动不可变，行为逻辑收束清晰

模块化项目中必须声明 permits 类在同一个模块

用 module-info.java 时，仅靠同包不够；permits 列表里的类所属模块，必须在密封类所在模块的 exports 或 opens 中显式暴露，否则编译期就无法解析类引用。

• 常见错误：子类在另一个模块，但主模块没 exports 对应包，导致 cannot find symbol
• 更隐蔽的问题：子类模块依赖了密封类模块，但密封类模块未 requires 子类模块（反向依赖不合法），会导致链接失败
• 建议优先采用非模块化结构起步，等模型稳定后再切模块，避免早期被模块约束卡住迭代

最容易被忽略的是 non-sealed 的传染性——它不警告、不报错，只是悄悄让整个继承分支退出密封体系。一旦某个业务敏感类型（比如 AdminRole）被设为 non-sealed，外部任意包都能继承它，领域约束就形同虚设。