switch语句默认不终止分支执行，匹配case后会顺序穿透至break/return/throw或switch结束；漏写break虽非语法错误，但90%属疏忽，易致逻辑错乱、状态异常、资源泄漏等严重问题，现代工具已将其列为高危警告。

因为 switch 语句本身不自动终止分支执行。一旦匹配到某个 case，程序就从那里开始顺序执行，不会因为下一个 case 的值不匹配就停下——它只认标签位置，不重新判断条件。

底层执行机制决定穿透是默认行为

编译器把每个 case 当作跳转标签（label），switch 实际上是“跳到匹配的标签，然后一路往下跑”。中间没有隐含的拦截点，除非遇到 break、return、throw 或 switch 块结束。

• 这不是 bug，而是 C 语言时期延续下来的设计选择，初衷是支持多值共享逻辑（比如多个 HTTP 状态码共用一个处理函数）
• 但这种灵活性代价很高：语法允许穿透，语义却极易偏离预期
• 现代语言（Java、C++17、JavaScript）并未取消该行为，只是加强了警告机制

漏写 break 的后果不是“多执行一行”，而是失控蔓延

看似只少了一个关键字，实际破坏了控制流边界，让本该隔离的逻辑单元被强行串联：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 输入为 1，却触发了 case 1、case 2、default 全部逻辑
• 状态机里从 IDLE 直接掉进 ERROR，跳过所有校验和初始化步骤
• 库存扣减执行两次 → 超卖；文件被 fopen 两次 → 句柄泄漏；权限检查后没中断 → 高危操作被无条件执行

为什么工具总报“Missing break”警告？

统计显示，90% 以上的穿透都不是有意设计，而是疏忽。IDE 和编译器（如 javac -Xlint、gcc -Wimplicit-fallthrough）把漏 break 列为高危信号，是因为它在真实系统中容易放大成连锁故障——日志错乱、监控失真、异常堆栈被掩盖，排查时根本找不到入口点。

哪怕你真想穿透，也必须显式写 // fall through —— intentional，否则工具仍会警告。这不是限制自由，而是把“我知道我在做什么”变成可验证的契约。