重构继承树为密封类是分阶段契约收束过程：先新建密封接口/类并保留旧类为过渡，用non-sealed保留扩展点，以record+sealed替代dto继承链，并适配反射与序列化。
直接重构继承树为密封类不是“一刀切”的替换，而是一次有节奏的、分阶段的契约收束过程。核心在于不破坏现有二进制兼容性，同时逐步建立编译期可验证的类型边界。
先锁定接口或抽象基类，而非立即改写具体实现
旧项目往往存在大量 extends BaseHandler 或 implements EventProcessor 的散落子类。此时不应立刻把 BaseHandler 改成 sealed class——这会导致所有已有子类编译失败。正确做法是：
- 新建一个同语义的密封接口或抽象密封类（如
public sealed interface PaymentStrategy permits AlipayStrategy, WechatStrategy） - 让老基类继续存在，但标注
@Deprecated并在 JavaDoc 中明确提示“新扩展请实现密封接口” - 将原有子类逐步迁移为密封体系下的
final实现，保留老类作为过渡桥接器（例如让OldAlipayHandler实现新接口并委托给自身逻辑）
允许 non-sealed 子类作为过渡层
当部分子类本身已是框架插件或由第三方维护，无法立即收口时，可用 non-sealed 保留下游扩展能力，同时维持父级密封契约：
- 定义
public sealed abstract class Command permits SyncCommand, AsyncCommand, CustomCommand - 其中
CustomCommand声明为public non-sealed class CustomCommand extends Command - 这样既满足了主干类型可穷尽匹配的要求，又为定制化留出入口，避免阻塞上线节奏
用记录类 + 密封类组合替代臃肿的 DTO 继承链
很多旧项目用继承表达状态变体（如 SuccessResult / ValidationError / TimeoutResult），导致 instanceof 泛滥。升级时可转向更清晰的代数数据类型建模：
- 将原抽象基类（如
Result）改为public sealed interface Result permits Success, Error, Timeout - 各分支用
record实现：public record Success(String data) implements Result - 配套更新
switch (result)表达式，利用编译器穷尽检查替代运行时if-else instanceof - 旧代码仍可通过
Result r = new Success("ok")调用，无 API 断层
配套改造反射与序列化逻辑
密封类对反射友好度较低，尤其涉及 Class.forName() 动态加载或 Jackson 反序列化时容易出错：
- Jackson 需显式注册子类型：
mapper.registerSubtypes(new NamedType(Success.class, "success")) - 避免使用
getDeclaredClasses()扫描子类——应改用getPermittedSubclasses()（Java 17+）获取白名单 - 若依赖 Spring 的自动装配（如
@Autowired List<handler></handler>），需配合@ConditionalOnClass或模块化扫描策略，防止 non-sealed 子类注入失控
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
