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

因为 switch 语句本身不自动终止分支执行，一旦匹配到某个 case，程序就从那里开始“一路往下跑”，直到遇到 break、return、throw，或者整个 switch 结束。漏写 break 不是语法错误，但会让本该独立的逻辑被强行串联，轻则输出错乱，重则状态错乱、资源重复操作、权限误放。

case穿透不是bug，而是设计特性

早期 C 语言为支持“多个值共享同一段处理逻辑”，刻意让 case 之间可自然贯通。比如：

• 多个 HTTP 成功码（200/201/204）共用 handleSuccess()
• 成绩等级 A/B/C 对应同一类提示逻辑

这种写法合法且高效，但前提是——你得明确知道自己在“有意穿透”。现实中，90% 以上的漏 break 是疏忽，不是设计。

Switch Modes

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

下载

穿透会直接破坏控制流边界

一个 case 本应是一个独立响应单元，漏 break 后它就失去了“作用域感”：

• 输入为 1，却触发了 case 1、case 2、default 全部逻辑
• 用户选“退出”，结果顺带执行了“清空缓存”“注销登录”“删除临时文件”
• 状态机里从 IDLE 穿透到 RUNNING 再掉进 ERROR，跳过所有校验和初始化

真实系统中可能引发连锁故障

看似只少了一行 break，但在复杂业务中容易放大成严重问题：

• 数据被多次修改：如库存扣减执行两次，导致超卖
• 资源重复申请：文件被 fopen 两次，句柄泄漏；线程被重复启动
• 安全边界失效：权限检查 case 后没 break，后续高危操作被无条件执行
• 日志与监控失真：错误状态未被捕获，异常堆栈被掩盖，排查时找不到入口点

现代工具已把漏 break 当作高危信号

主流 IDE（IntelliJ、VS Code + Java/C++ 插件）、编译器（javac -Xlint、gcc -Wimplicit-fallthrough）默认开启穿透警告。这不是小题大做——它是工程实践中用无数线上事故换来的经验共识。哪怕你真想穿透，也建议显式加注释，比如：

// fall through —— intentional