java密封接口必须用sealed声明并显式列出permits类型，且所有实现类需在同一模块或源根下；未导出的实现类会导致运行时错误，反射和序列化不自动识别密封性。
Java密封接口怎么声明才能真正限制实现类
密封接口不是加个 sealed 就完事——必须显式列出所有允许的实现者，否则编译器直接报错。JDK 17+ 要求 permits 子句不能省略，且列出的类/接口必须与密封接口在同一个模块（或同一源根下），否则会提示 class is not in the permits clause of its sealed supertype。
常见错误是只写 sealed interface Shape permits Circle，但 Circle 是 final 类却没放在同一包里，或者忘了加 non-sealed 允许后续扩展的例外情况。
-
permits后面的类型名必须是已声明的、可访问的类或接口，不能是字符串或未定义符号 - 如果想让某个子类还能被继承，它自己得声明为
non-sealed；否则默认是final行为（即使没写final） - 模块化项目中，若密封接口在
module-info.java中导出，而实现类没导出，会导致运行时NoClassDefFoundError，和编译期限制无关但实际拦不住反射
密封接口配合 switch 模式匹配做穷举判断
密封接口的核心价值之一是让 switch 在编译期就能确认是否覆盖所有可能分支。前提是 switch 的表达式类型是密封接口，且所有 permits 类型都作为 case 出现（或用 default + 注释说明“此处不可达”）。
容易踩的坑是：有人以为加了 sealed 就自动支持模式匹配，其实还得用 switch 表达式语法（JDK 14+ 预览，JDK 17+ 正式），老式语句式 switch 不触发穷举检查。
立即学习“Java免费学习笔记（深入）”；
- 必须用
switch (shape) { case Circle c -> ...; case Rectangle r -> ...; }这种箭头语法 - 如果漏掉某个
permits类型，编译器报错：the switch expression of type Shape does not cover all possible values - 不能用
instanceof替代——它绕过密封约束，也失去编译期保障
为什么不能用 final 类代替密封接口来控制API边界
因为 final 类禁止继承，但无法表达「我只接受这几种子类型」的契约；而密封接口明确划出实现边界的轮廓，既防外部随意实现，又保留内部可控扩展能力。
典型误用场景：工具类想限定输入只能是几种预定义形状，结果定义了 final class Circle 和 final class Rectangle，再写一个 process(Shape shape) 方法——但用户仍可自己写个新类实现 Shape 并传入，除非 Shape 是密封的。
- 接口本身不实例化，所以密封接口限制的是「谁可以实现我」，不是「谁可以使用我」
- 如果把 API 参数类型设为密封接口，调用方就只能传入你白名单里的实现类（或其子类，取决于是否
non-sealed） - 相比 package-private 抽象类，密封接口更灵活：支持跨包协作，且不强制继承关系
密封接口在 Spring 或 Jackson 场景下的兼容性风险
框架往往依赖反射或动态代理，而密封类/接口的 permits 信息在运行时不可反射获取（getPermittedSubclasses() 是 JDK 16+ 新增方法，但 Spring、Jackson 默认不识别）。这意味着：序列化/反序列化可能失败，AOP 代理可能绕过密封约束。
比如用 Jackson 反序列化 JSON 到密封接口 Shape，不配 @JsonSubTypes 或模块注册，会抛 InvalidDefinitionException: Cannot construct instance of Shape。
- Spring Boot 3.2+ 开始实验性支持密封类绑定，但需手动启用
spring.main.allow-sealed-classes=true - Jackson 必须显式配置多态类型处理，例如用
@JsonTypeInfo+@JsonSubTypes映射每个permits类型 - 不要指望
ObjectMapper.readValue(json, Shape.class)自动推断实现类——它没读permits元数据
密封性的真正防线只在编译期和设计意图层面；运行时一切反射、字节码操作、JSON 序列化都可能撕开口子。别把它当成安全沙箱，而是当作一种更强的 API 合约表达方式。
