sealed类必须显式声明permits且子类需为final/sealed/non-sealed；同包或同模块下全限定名匹配、module-info正确导出，才能启用穷尽模式匹配。
直接结论：用 sealed + permits 能拦住非法子类，但拦不住的前提是——你写对了位置、配对了修饰符、守住了包/模块边界；否则编译器根本不会校验，等于白写。
为什么 sealed 类不加 permits 就编译失败
Java 17 不支持隐式推导允许的子类，permits 是强制语法成分。漏写、拼错类名、大小写不符、写了内部类或匿名类，都会触发编译错误：error: sealed class must have a permits clause 或 error: class X is not allowed to extend sealed class Y。
-
permits后的类名必须是全限定名（如Pending而非com.example.order.Pending）——仅当子类与密封类同包时才可省略包前缀 - 如果子类在另一个包里，即使加了
public，也会报错，因为 Java 17 默认要求同包（非模块化项目）或同模块（模块化项目） - 模块化项目中，仅同包不够：必须在
module-info.java中对子类所在包做exports，否则编译期就cannot find symbol
子类必须显式声明 final/sealed/non-sealed
这不是风格建议，是编译器硬性要求。不加三者之一，直接报错：error: non-sealed, sealed or final expected。
-
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使用最自然：字段自动不可变，行为逻辑收束清晰，避免手写构造器和equals的疏漏
模块化项目中 permits 类必须在同一个模块
模块不是可选项——一旦用了 module-info.java，仅靠同包完全不够。permits 列表里的每个类所属模块，必须在密封类所在模块的 exports 或 opens 中显式暴露。
- 常见错误：子类在另一个模块，但主模块没
exports对应包 → 编译期cannot find symbol - 更隐蔽的问题：子类模块依赖了密封类模块，但密封类模块未
requires子类模块 → 链接失败（反向依赖不合法） - 建议优先采用非模块化结构起步，等模型稳定后再切模块，避免早期被模块约束卡住迭代
最容易被忽略的是 non-sealed 的退出机制——它不报错、不警告，只是让整个分支脱离密封体系。一旦用了，你就得手动保证后续所有子类的行为合规，编译器不再帮你兜底。
