新增许可子类会触发所有switch表达式编译报错，这是Java17+静态穷尽性检查的设计意图；需用IDE快速定位并补全case分支，结合模式匹配提升可维护性。
新增一个许可子类后，所有针对该密封类型（接口或类）的 switch 表达式会立刻报错，这不是 bug，而是密封机制的设计意图——它强制你显式处理新增变体，避免逻辑遗漏。
理解编译报错的本质
Java 17+ 的 switch 表达式对密封类型（包括 sealed interface/class 和 enum）执行**静态穷尽性检查**。只要密封类型新增了许可子类，所有已存在的 switch 就必须覆盖它，否则编译失败。这是类型安全的“守门人”，不是障碍。
快速定位并修复所有 switch 点
不要逐个手动查找，利用 IDE 的导航能力高效处理：
- 在密封类型声明处右键 → “Find Usages”（IntelliJ）或 “References”（Eclipse），筛选出所有
switch表达式调用点 - 对每个匹配的
switch，光标停在switch关键字上，按快捷键（如 IntelliJ 的Alt + Enter），IDE 会自动提示“Add missing case branches”，一键补全新子类分支 - 补全后，根据业务语义填写对应逻辑，例如新增
BankTransfer就补case BankTransfer b -> handleBankTransfer(b)
避免重复劳动：提前约定处理模板
团队协作中可建立规范，减少重构时的沟通成本：
- 所有处理密封类型的
switch必须使用表达式形式（switch (...) -> { ... }），而非语句形式（switch (...) { ... }），前者才触发穷尽检查 - 为每个密封类型配套一个统一的处理工具类，比如
PaymentMethodHandlers，集中封装各子类的默认行为或 fallback 逻辑 - 若某处暂时无法实现新子类逻辑，可用
throw new UnsupportedOperationException("Not yet supported: " + p.getClass().getSimpleName())占位，保留编译通过，但明确标记待办
配合 Pattern Matching 提升可维护性
在补充分支的同时，顺势升级写法，让逻辑更清晰、更安全：
- 用模式变量替代传统 instanceof + 强转，例如
case Alipay(String accountId, String realName) -> {...}直接解构 - 避免在
switch外再做类型判断，所有分支都应基于密封类型本身展开，不混用instanceof - 若分支逻辑复杂，提取为私有方法，保持
switch主体简洁，便于后续新增时快速理解上下文
