密封类通过编译期强制契约限定继承者，需用sealed+permits明确白名单，子类须显式声明final/sealed/non-sealed，配合模块系统阻止跨模块非法实现，并使switch具备穷尽性检查能力。
密封类的“封口”不是物理锁，而是编译期的契约强制——它把“谁可以继承我”从靠文档提醒、靠开发者自觉，变成一条编译器必须检查的硬规则。第三方哪怕写对了方法签名、加对了 implements，只要没出现在 permits 名单里，就通不过编译。
用 sealed + permits 划清继承白名单
在框架核心抽象（如接口或抽象类）上明确使用 sealed 修饰，并通过 permits 列出所有你认可的子类型。这些子类型必须与密封父类型在同一个模块中（或按模块系统显式授权）。
- 例如定义一个支付协议接口：public sealed interface PaymentStrategy permits CreditCard, PayPal, BankTransfer
- 任何第三方包里写的 class WeChatPayImpl implements PaymentStrategy 都会直接报错：“class WeChatPayImpl is not allowed to implement sealed interface PaymentStrategy”
- 这个检查发生在写代码时，不是运行时，更不是上线后才发现逻辑分支缺失
要求子类声明自身继承意图
被允许的子类不能“悄悄继承”，必须用 final、sealed 或 non-sealed 显式说明自己的扩展策略：
- final 子类（如 final class CreditCard）彻底封闭，杜绝再继承
- sealed 子类可继续控制下一层（比如 sealed class ValidationError permits MissingFieldError, InvalidFormatError）
- non-sealed 是唯一开放口，但必须由你主动授予，且仅限你设计好的扩展点（如允许业务方在 ValidationError 下定义具体错误码）
配合模块系统堵死跨模块非法实现
仅靠 sealed/permits 还不够——如果第三方把子类打到另一个模块，仍可能绕过限制。这时需在 module-info.java 中声明许可：
- 在框架模块中写：exports com.example.payment to com.example.payment.impl
- 在实现模块中写：requires com.example.payment
- 再配合 permits 列表只包含本模块内类，JVM 加载阶段就会拒绝非法继承关系，反射也无法绕过
让模式匹配成为自动校验器
当第三方无法新增子类，所有合法子类型就是已知且有限的。这使得 switch 表达式能开启穷尽性检查：
- 写 return switch (strategy) { case CreditCard c -> ...; case PayPal p -> ...; }
- 如果未来你新增 ApplePay 子类但忘了更新所有 switch，编译器立刻报错：“missing case: ApplePay”
- 这种反馈闭环倒逼框架维护者和使用者共同守住继承边界，而不是靠人肉 Review
