java密封类通过sealed interface限定协议帧类型，配合record实现不可变数据载体，并用switch模式匹配实现编译期穷尽检查，确保类型安全与可维护性。
在物联网消息解析器中，用Java密封类闭合协议帧类型，核心是让编译器帮你守住“只允许这几种帧能被处理”的契约，避免非法帧类型混入、漏处理或运行时类型错误。
定义密封接口表示协议帧顶层抽象
用sealed interface作为所有合法帧的统一入口，明确列出全部支持的帧类型，不遗漏、不开放：
- 接口必须加
sealed修饰符，并用permits穷举所有实现类（如HeartbeatFrame、TelemetryFrame、CommandFrame） - 所有
permits中的类必须与接口在同一模块，且不能是抽象类（除非它自己也声明为sealed） - 示例：
public sealed interface IotFrame permits HeartbeatFrame, TelemetryFrame, CommandFrame { }
用record实现具体帧类型，保证不可变与轻量
每个协议帧本质是携带固定字段的数据载体，用record天然契合：
-
record自动提供构造器、字段访问器、equals/hashCode/toString，减少样板代码 - 不可变性防止解析过程中意外修改帧内容，提升线程安全和调试可预测性
- 示例：
public record TelemetryFrame(String deviceId, double temperature, long timestamp) implements IotFrame { }
在解析逻辑中用switch模式匹配做穷尽分支处理
借助密封结构，编译器能验证switch是否覆盖所有可能帧类型，杜绝漏处理：
- 对
IotFrame变量使用switch表达式，每个case对应一个record类型 - 编译器强制要求列出全部
permits类型，缺一个就报错；加上default反而会提示“冗余”，因为已穷尽 - 模式匹配还能自动解构字段，比如
case TelemetryFrame(String id, double t, long ts) -> { /* 直接用id、t、ts */ }
控制扩展边界：按需开放或锁定子类型
未来若需新增帧类型（如ConfigFrame），必须显式加入permits列表并定义其实现；若某类帧需进一步细分（如CommandFrame分RebootCmd和UpdateCmd），可将其声明为sealed并设新permits：
-
final：适合终端帧类型（如HeartbeatFrame），禁止任何继承 -
sealed：适合中间帧类型（如CommandFrame），可继续限定其子类 -
non-sealed：慎用，仅当必须兼容第三方扩展时才开放（如预留CustomFrame）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
