Java中switch直接匹配枚举值最安全，case必须是同一枚举类的编译期常量；default不可省，须抛异常确保失败可感知；避免在case中写重复逻辑，宜用策略模式解耦。
switch 怎么匹配 Java 枚举状态
Java 中 switch 直接支持枚举类型，不需要转成 int 或 String——这是最安全、最可读的方式。但前提是枚举类不能是匿名子类（比如带大括号实现抽象方法的），否则编译会报错 constant expression required。
常见错误：把枚举值写成 OrderStatus.PAID.toString() 或 status.name() 进 switch，这不仅多此一举，还会让 case 失去编译期检查，一旦枚举名改了就静默失效。
- 正确写法：
switch (order.getStatus()) { case PAID: ... case SHIPPED: ... } - case 标签必须是同一枚举类的**编译期常量**，不能是变量或方法调用
- Java 14+ 支持 switch 表达式（带 -> 和 yield），但老项目用传统语句块更稳妥
每个 case 里怎么写发货逻辑才不重复又不耦合
直接在 case 分支里写发 HTTP 请求、更新库存、生成运单等操作，短期快，长期难测、难改、难复用。核心矛盾在于：状态多（比如 PAYMENT_CONFIRMED、READY_TO_SHIP、AWAITING_PICKUP），但真正触发发货动作的往往只有其中一两个。
Switch Modes
下载
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 只在真正需要发货的 case 里调用
dispatchService.dispatch(order)，其他状态跳过或抛IllegalStateException - 避免在 switch 里做状态变更（如
order.setStatus(SHIPPED)），应由 service 方法内部统一处理 - 如果不同状态发货逻辑差异大（比如 B2B 走 ERP 接口，B2C 走快递平台），考虑用策略模式 + Map<OrderStatus, DispatchStrategy>，switch 只负责路由
为什么 default 分支不能省，也不能只写个 log
枚举新增状态后，如果 switch 没覆盖，又没 default，运行时就直接跳过，订单卡住不动——这种 bug 很难被测试覆盖，线上可能积压数小时才发现。
- default 必须抛异常，例如
throw new UnsupportedOperationException("Unknown order status: " + status) - 日志 + 异常能确保失败可感知；只打日志等于静默吞掉问题
- CI 阶段可加 Checkstyle 规则，强制所有枚举 switch 包含 default 且非空
- 如果业务允许“忽略未知状态”，也得明确写成
default -> {}（Java 14+ 表达式）或空语句块，并加注释说明原因
Kotlin 用户注意 when 的空安全与密封类替代方案
Kotlin 的 when 对枚举更友好，但如果你用的是 OrderStatus?（可空），直接 when (status) { PAID -> ... } 会编译失败：kotlin 要求穷尽所有可能，包括 null。
- 要么先非空断言：
checkNotNull(status)再 when - 要么显式处理 null：
when (status) { null -> throw IllegalArgumentException(...) } - 更彻底的解法：把订单状态定义为密封类（
sealed class OrderStatus），配合when编译器强制穷尽，比枚举还灵活（比如每个子类可携带不同上下文数据）
EXCEPTION_HANDLING 状态，前端传参、数据库字段、switch case、监控告警规则，四者漏一不可。别指望靠“后面再补”。 
