这是专栏第 3 篇。我对switch表达式的感受很明确：它不是“语法糖”，而是把分支逻辑从“容易漏细节”改成“默认更安全”。一、JDK 8 的switch，我最怕什么我在旧项目里最常见的写法是：先声明一个临时变量；switch里分支赋值；末尾统一return；新增分支时，手动补break。它能跑，但问题是太依赖人工细心：漏break、漏默认分支、漏赋值，都可能引入行为偏差。二、版本信息（含 JEP）JEP 325：Java 12（预览）JEP 354：Java 13（第二次预览，引入yield）JEP 361：Java 14（正式）现在我只建议在 JDK 17/21 使用正式能力，不建议新项目再走预览参数链路。三、switch表达式到底改变了什么1.switch变成“有返回值的表达式”从“写流程控制”变成“写输入到输出的映射”，这对业务代码非常实用。2.case L -默认不贯穿箭头写法不再隐式 fall-through，减少了老式break漏写风险。3. 复杂分支可用yield当某个分支需要多行逻辑时，块内计算后yield返回，语义非常清楚。四、适配场景 / 不适配场景适配场景：根据状态、类型、等级做值映射；分支较多且最终要返回统一结果；想让 review 一眼看到每个分支的输出。不适配场景：简单二分判断，if/else更直接；主要是副作用操作而不是返回值映射；仍被 JDK 8 运行时强绑定的模块。五、从 JDK 8 升级时，我会先盯这 6 件事1) 编译参数与工具链确保构建链最少到 JDK 14（生产建议 17/21），同步修正 IDE、CI 的 JDK 版本。2)null语义switch表达式在status == null时仍可能抛NullPointerException。这类输入要么先前置校验，要么在调用层约束非空。3) 分支完整性表达式必须保证每个分支都返回值。以前“默认走到外层变量”的写法在这里会被编译器直接拦住，这其实是好事。4)yield与return区分yield是把值交给switch表达式，return是直接返回当前方法。团队规范里最好写明，避免混用造成误读。5) 枚举扩展风险如果你对枚举做switch，新增枚举值后要明确处理策略：是让编译器强制你补全分支，还是保留default兜底。6) 静态扫描规则部分老规则默认case必须break，要同步升级规则集，不然 CI 会误报。六、落地方式（我会怎么改）优先改“返