Java 密封接口的核心思想其实非常直接：将“哪些消息体是合法的”这一业务规则从运行时判断转移到编译期处理。通过sealed与permits关键字显式声明允许的子类型，再结合模块封装、访问修饰符策略以及序列化白名单校验，最终形成的契约既能被静态验证，也无法被轻易绕过。
简单来说，使用密封接口来定义跨系统消息通知契约，其最大价值在于把“哪些消息体是合法的”这个业务规则从文档约定变为代码本身——不再依赖运行时校验或团队口头沟通，而是直接固化到编译期。这样做的好处非常明确：契约变得可验证、不可绕过，错误在开发阶段就会被捕获。接下来详细拆解具体实现步骤。
用 sealed + permits 明确列出所有允许的消息体类型
消息通知契约通常体现为一个统一的入口接口，比如 Notification。不同业务场景对应不同的消息体，如订单确认（OrderConfirmed）、支付失败（PaymentFailed）、用户注册（UserRegistered）等。密封接口强制要求以下约束：
- 所有合法消息体必须在 permits 子句中显式列出，例如：
public sealed interface Notification permits OrderConfirmed, PaymentFailed, UserRegistered - 每个列出的类必须与接口位于同一模块内，不能是抽象类，也不能使用默认访问修饰符
- 外部系统若想添加新消息类型，必须向该模块提交代码变更并重新编译——这天然构建了一个接入审批流程，防止随意扩展
为每个消息体选择合适的封闭策略
并非所有消息体都需要完全封死。应根据扩展需求灵活选择实现类的修饰符：
- final：适用于结构稳定、绝不允许额外字段的消息，例如
public final class OrderConfirmed implements Notification - sealed：适用于需要分层建模的场景，比如所有支付类消息共享一个父类型
PaymentEvent，再由PaymentSucceeded和PaymentRefunded继承 - non-sealed：仅对极少数需要保留现场扩展能力的类型开放，例如测试环境中的
MockNotification。生产环境建议避免使用此策略
配合模块封装隐藏实现细节
仅仅依靠密封性还不够，反射或跨模块非法实例化仍需防范。需要在 module-info.java 中精准控制可见性：
- 仅 exports 定义契约的包（比如
com.example.notification），不导出具体消息体所在的包 - 不 opens 实现类包给其他模块，除非确有需要（例如序列化框架要求）
- 对外 API 全部使用
Notification接口类型，避免暴露OrderConfirmed等具体类名
与消息序列化/反序列化机制协同
密封接口本身不处理序列化，但能大幅提升安全性：
- 反序列化时，可基于
permits列表进行白名单校验，拒绝任何未知类型字符串 - 结合 Jackson 或 Gson 的模块配置，只注册已知实现类，避免自动发现引入的安全风险
- 配合 Java 21 的模式匹配 switch，能写出穷尽性检查的消费逻辑——编译器会提示是否遗漏了某类消息
总体而言，这套组合拳让消息通知契约从纸面约定变为实实在在的代码级约束。开发者无需在运行时反复校验，也无需担心有人绕过规则——编译期就将其拦截在外。
