switch中case是跳转标签而非条件判断块，匹配后会顺序执行后续所有case直至break/return等终止，导致副作用连锁触发、逻辑失控和隐蔽bug。

因为 switch 里的 case 不是“条件判断”，而是“跳转标签”。程序一旦匹配到某个 case，就从那里开始执行，然后一条接一条往下跑，直到遇到 break、return、throw 或 switch 结束为止——它不会自动停在当前 case 的末尾。

case 本质是入口点，不是隔离块

编译器把每个 case 当作一个标记位置（类似 goto 标签），而不是独立作用域。漏写 break，等于告诉程序：“执行完这几句，接着往下走，别管下一个 case 是不是匹配。” 所以哪怕后续 case 的值完全不相关，只要代码在它里面，就会被执行。

• 比如 score = 95，匹配 case 'A'，但没写 break，程序会继续执行 case 'B'、case 'C' 直到结束
• 用户选了“保存”，结果“删除”和“退出”逻辑也被顺带触发
• 状态机中本该从 “IDLE” 进入 “RUNNING”，却一路贯穿到 “ERROR” 和 “SHUTDOWN”

业务逻辑常依赖顺序与独占性

真实业务代码很少只打印一句话，往往包含函数调用、变量修改、资源操作等副作用。多个 case 被连着执行，意味着这些副作用被重复或错序触发：

Switch Modes

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

下载

• 数据库插入一次 → 又插入一次 → 主键冲突或数据重复
• 文件打开一次 → 再打开一次 → 句柄泄漏或覆盖写入
• 权限校验通过 → 接着执行管理员操作 → 权限绕过漏洞
• 支付请求处理 → 又触发退款逻辑 → 资金异常变动

default 也会被“卷入”贯穿路径

default 并不特殊，它只是最后一个可执行分支。如果它前面的 case 没 break，且 default 不在末尾（比如写在中间），程序照样会穿过它继续执行后面的 case；如果 default 在末尾但没 break，它执行完还会继续跑出 switch ——虽然通常不会出错，但逻辑已失控。

• 示例：输入非法字符，触发 default 输出错误提示，紧接着又执行了 case 'Q' 的退出逻辑
• 更隐蔽的是，default 后面若还有 case（语法允许），那些 case 也会被误执行

调试时很难一眼发现

输出看起来“多执行了几行”，但没人会立刻想到是 switch 漏了 break。尤其当 case 块较长、嵌套 if 或调用外部函数时，日志可能分散、状态变化延迟显现，错误表现和根源相隔很远。

• 前端点击按钮只应刷新列表，结果用户被登出 + 缓存清空 + 数据上报全部触发
• 日志里看到三段不同模块的日志紧挨着出现，但代码分布在四个 case 里
• 单元测试只覆盖单个分支，集成后才发现贯穿导致连锁反应