密封接口规范跨系统消息通知契约并精确限制消息体子类型

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，能写出穷尽性检查的消费逻辑——编译器会提示是否遗漏了某类消息

总体而言，这套组合拳让消息通知契约从纸面约定变为实实在在的代码级约束。开发者无需在运行时反复校验，也无需担心有人绕过规则——编译期就将其拦截在外。