关键在于用枚举类型本身作switch表达式，java 14+通过省略default的箭头语法触发编译期穷尽检查，新增枚举值时立即报错；禁用ordinal()/name()转换，配合单元测试和ci警告形成闭环验证。

关键不是“写了 switch”，而是让编译器能确认你正在处理一个封闭、有限、所有取值都已知的类型，并在新增枚举值时立刻报错提醒你补逻辑。

用枚举类型本身作 switch 表达式

必须确保 switch 的入参变量声明类型就是 enum，比如 Status status，而不是 int、String 或 Object。编译器只对明确的枚举类型做穷尽分析。

• ✅ 正确：switch (status) { case PENDING -> ... }
• ❌ 错误：switch (status.ordinal()) { ... } 或 switch (status.name()) { ... }——这会让编译器彻底失去校验能力

启用 Java 14+ switch 表达式语法

使用箭头（->）写法，不写 default 分支，是触发编译期穷尽检查的前提。

Switch Modes

动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。

下载

• 每个 case 必须返回相同类型的值（例如全是 String）
• 不能混用冒号（:）和 break，否则退化为传统语句，失去检查能力
• 一旦枚举新增一个常量（如 ARCHIVED），编译直接失败，错误信息明确指出“missing case label for ARCHIVED”

慎用或不用 default 分支

default 看似安全，实则可能掩盖新增项导致的逻辑静默失效。

• 纯内部业务逻辑、确定枚举封闭 → 不写 default，靠编译报错驱动补全
• 必须兼容外部输入或预留扩展 → default 中抛出 IllegalArgumentException("Unexpected: " + status)，并附带完整上下文
• 避免空 default、return null 或仅 log.warn，这些都会绕过问题暴露

配合单元测试闭环验证

编译检查是第一道防线，但测试能覆盖反射调用、序列化反解等边界场景。

• 遍历 Status.values()，对每个值调用该 switch 方法，断言返回结果非 null 或符合预期
• CI 流程中启用 -Xlint:switch 并设为 error 级别，防止本地忽略警告
• 用 IDE 的 “Find Usages” 检查某枚举新增后，所有 switch 使用点是否同步更新