不写 break 会导致穿透（fall-through），即从匹配 case 开始持续执行至下一个 break、return、throw 或 switch 结束；这是 Java 明确规定的语义，非 bug。
Java switch 不写 break 会怎样
不写 break 就会穿透（fall-through）——从匹配的 case 开始，一路执行到下一个 break、return、throw 或 switch 结束为止。这不是 bug，是 Java 明确规定的语义。
常见错误现象：case 1: 后没加 break，结果 case 2: 的逻辑也执行了，但调试时看不出明显报错，只发现业务逻辑“多走了一步”。
- 只有
case和default标签本身不终止执行，break是唯一显式跳出当前case块的手段 -
return和throw也能阻断穿透，但它们会退出整个方法或抛异常，语义不同 - Java 14+ 的
switch表达式（用->的那种）默认不穿透，和传统语句式switch是两套规则，混用容易误判
什么时候该主动利用 fall-through
真正需要穿透的场景其实很少，但存在——核心是「多个离散值共享同一段逻辑」，且语义上天然连续。
典型使用场景：按数字范围做分类，比如 HTTP 状态码分组处理；或者枚举状态的聚合判断。
立即学习“Java免费学习笔记（深入）”；
- 避免重复写相同逻辑：比如
case 200:、case 201:、case 204:都算“成功”，共用一个处理分支 - 必须确保顺序正确：
case 200:和case 201:要紧挨着，中间不能插别的case，否则穿透会带入无关逻辑 - 强烈建议加注释说明意图，例如
// fall-through，否则团队成员极大概率把它当成漏写break
示例：
switch (statusCode) {
case 200:
case 201:
case 204:
handleSuccess(); // 共享逻辑
break; // 这个 break 必须有，否则会掉进 default
default:
handleError();
}
为什么现代 IDE 总警告“Missing break in switch”
因为绝大多数穿透都是意外发生的。统计显示，90% 以上的漏 break 是疏忽，不是设计。
IDE（如 IntelliJ）默认开启检查，不是为了阻止你用穿透，而是帮你拦截低级错误。它不管你的业务是否真需要穿透，只看语法结构是否闭合。
- 如果确实需要穿透，必须显式写
// fall-through注释，多数 IDE 识别后会关闭警告 - 不要用
@SuppressWarnings("fallthrough")全局压制——它会掩盖真正的问题 - 在
switch块末尾的default后漏break通常无害（因为已是结尾），但依然建议统一加上，保持风格一致
switch 表达式（->）和语句式（:）的 fall-through 差异
这是最容易混淆的点：Java 14 引入的 switch 表达式默认不穿透，和旧式语句完全不兼容。
如果你把原来带穿透的语句式 switch 直接改成表达式写法，逻辑会出错——因为每个 case 分支自动结束，不再往下跑。
- 语句式（冒号
:）：需手动break控制流程 - 表达式式（箭头
->）：每个分支独立求值，自动终止；想“合并多个值”得用逗号分隔，例如case 200, 201, 204 -> handleSuccess() - 混合使用时，别假设行为一致——尤其在重构遗留代码时，先确认原逻辑是否依赖穿透
穿透本身没有对错，但它的可读性和维护成本很高。一旦涉及三个以上 case 的穿透链，人眼几乎无法快速判断执行路径。最危险的不是不会用，而是用了却不自知。
