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 的退出机制——它不报错、不警告，只是让整个分支脱离密封体系。一旦用了，你就得手动保证后续所有子类的行为合规，编译器不再帮你兜底。