Java sealed interface 的 permitted subclasses 怎么影响扩展

Java 的 sealed interface 解决的是“这个接口允许哪些直接实现者”这一类边界问题。把 permits 写上后，列表中的类或子接口必须直接 implements 或 extends 它；其他类型不能悄悄插入这一层。直接实现者还必须明确选择 final、sealed 或 non-sealed，所以它既能收紧领域模型，也能把需要开放的分支标出来。

可以把 sealed interface 理解成编译期可见的类型边界：它限制继承关系和穷举分析，但不是运行时权限系统。设计它时，既要看 permits，也要看模块、包、第三方实现和兼容性。

sealed interface 如何把实现边界写进类型层级

下面的例子把支付方式限定为三条直接分支。CardPayment 是叶子类型，WalletPayment 仍由本模块继续管理，CashPayment 则明确表示后续实现可以开放。

// 根接口只允许这三个直接实现者进入本层级
sealed interface PaymentMethod permits CardPayment, WalletPayment, CashPayment {}

// final 到此结束，不能再有子类
final class CardPayment implements PaymentMethod {}

// sealed 表示下一层仍然需要显式列出允许的类型
sealed class WalletPayment implements PaymentMethod permits CorporateCard {}
final class CorporateCard extends WalletPayment {}

// non-sealed 重新打开这条分支，后续实现不再受本 permits 列表限制
non-sealed class CashPayment implements PaymentMethod {}

这里最容易混淆的是“直接”和“间接”。CorporateCard 不需要再出现在 PaymentMethod 的 permits 中，因为它直接继承的是 WalletPayment。相反，如果某个类直接实现 PaymentMethod 却没有出现在列表里，编译器会拒绝它。

final、sealed、non-sealed 分别意味着什么

三种声明不是风格选择，而是层级契约：

接口的直接子接口也遵循同样的规则。省略 permits 并不等于完全开放：编译器会从同一编译单元中寻找具有规范名称、且直接实现或继承该接口的类型；如果找不到允许的直接类型，声明本身就是错误。记录类隐式为 final，因此可以作为 sealed interface 的叶子实现。

扩展边界与兼容性要一起评估

sealed 的安全价值主要是防止不受控的类型进入领域层级，不应替代认证、授权或输入校验。接口和直接实现者需要互相引用，在命名模块中通常应放在同一模块；未命名模块下还要注意同一包约束。把实现分散到不同维护边界，往往会在编译阶段暴露问题。

如果这是一个已经发布给第三方使用的普通接口，后来直接改成 sealed，第三方实现可能无法重新编译；旧的、不在允许列表中的二进制实现加载时还可能触发 IncompatibleClassChangeError。从 sealed 层级中移除已有直接实现者同样需要谨慎。新增允许的直接实现者通常不破坏既有二进制链接，但会改变依赖穷举分支的维护责任。

落地前的检查清单

• 先问清楚谁拥有这组领域状态；如果需要第三方自由实现，普通 interface 可能更合适。
• 逐个检查 permits 类型是否为直接实现者或直接子接口，并确认名称唯一且可访问。
• 为每个直接实现者明确写出 final、sealed 或 non-sealed，不要让开放性靠默认行为猜测。
• 检查模块、包和发布 API 的兼容承诺，再评估基于 sealed 层级的穷举 switch。

相关规则可对照 Java 语言规范接口章节、二进制兼容章节 和 switch 穷举规则。真正的判断标准不是“能不能写 sealed”，而是这组类型是否确实应该由同一个维护边界负责演进。

常见问题

permits 能不能写一个间接子类？

不能。它只接受直接实现者或直接子接口；间接后代应由上一层的 sealed 声明继续管理，或被 final 终止、被 non-sealed 放开。

sealed interface 是不是可以防止别人运行时伪造实现？

它不是访问控制或反篡改机制，而是 Java 类型系统和类文件约束的一部分。需要保护真实资源时，仍然要在运行时做身份、权限和输入验证。