防范non-sealed破坏密封约束的核心是坚守“许可即管控”原则：一旦子类标为non-sealed，即脱离密封体系，后续继承不受编译器校验；其使用仅限框架插件点、需多态演进的策略分支等特定场景，且须配套SPI契约、白名单校验或模块访问控制；每个permits子类必须显式声明final/sealed/non-sealed；non-sealed类须在Javadoc中警示扩展风险；需通过包封装与模块exports/opens双重隔离非法继承；switch穷尽性检查在存在non-sealed分支时失效，须辅以反射扫描、字节码分析及IDE实时检测。
防范non-sealed破坏密封约束，核心是守住“许可即管控”这一原则——只要某个子类被标为non-sealed，它就脱离整个密封体系，后续任意继承都不再受编译器校验。这不是配置疏漏，而是设计决策的显式暴露。
严格限制non-sealed的使用场景
non-sealed不是“可选宽松项”，而是主动打开的扩展闸门。只在以下情况考虑使用：
- 框架预留插件点（如自定义支付网关、日志适配器），且该扩展点有明确的SPI契约与沙箱隔离机制
- 领域模型中某分支天然需支持多态演进（如“策略”类下的算法变体），但必须配套运行时白名单校验
- 已通过模块exports/opens+服务发现机制对扩展入口做了访问控制，而非仅依赖语言语法
强制子类声明封闭性策略
每个permits列出的子类必须显式标注final/sealed/non-sealed，缺一不可。编译器不会默认补全，也不会给出友好提示——漏写直接报错，错写则导致类型系统失效。
- final：适用于状态确定、行为不可覆盖的领域实体（如OrderStatus枚举替代类）
- sealed：适用于还需分层建模的中间抽象（如PaymentMethod → CreditCard / BankTransfer）
- non-sealed：必须同步在Javadoc中标明“此类型开放扩展，调用方须自行校验实现合法性”
模块边界与包可见性双重加固
即使子类用了non-sealed，也要阻断非法继承路径：
- 非模块化项目：将所有密封类及其permits子类放在同一包内，且不导出该包给无关模块
- 模块化项目：在module-info.java中仅exports密封类所在包，且不exports被标记为non-sealed的子类所在包
- 若必须开放某non-sealed子类，应将其移至独立模块，并通过requires+uses声明依赖，而非直接暴露实现包
模式匹配时验证穷尽性是否真正成立
switch表达式去掉default分支的前提，是编译器确认所有可能类型已被覆盖。一旦某permits子类是non-sealed，该分支下所有潜在子类型都不可知，穷尽性检查即失效。
- 单元测试中用反射扫描所有Shape子类，断言non-sealed分支下无未授权实现
- CI阶段加入字节码分析工具（如Byte Buddy或ArchUnit），校验non-sealed类是否出现在禁止包路径中
- IDE启用“Sealed Class Hierarchy Inspection”，实时高亮non-sealed节点并提示影响范围
