漏写 break 是 switch 穿透主因，需通过即时补终止、显式标注 fall through、启用 ESLint no-fallthrough、加强测试及采用 Map/数组/对象等更安全替代方案来防范。
漏写 break 是 switch 穿透最常见、也最容易修复的问题。它不是语法缺陷，而是语言明确设计的行为：匹配后不终止，就自然往下走。解决的关键不在“堵”，而在“防”和“显”——让意图清晰、让疏忽无处藏身。
养成即时补终止语句的习惯
每个 case 块写完，立刻检查末尾是否已有 break、return 或 throw。这是最直接的防线。
- 空
case必须加注释// fall through，否则 IDE 和 ESLint 会报错 - 如果该
case确实要共享后续逻辑（比如多个状态共用 loading 处理），就把意图写清楚，别靠“猜” -
default分支也别漏break，尤其当它不在最后时——switch 不因 default 出现就自动停
用工具自动拦截漏 break
人会疲劳，工具不会。把防御机制嵌入开发流程里，比每次靠眼睛盯更可靠。
- 在 ESLint 配置中启用
no-fallthrough规则，并设为error级别，保存即报错 - VS Code、WebStorm 等主流 IDE 默认高亮无终止语句的非末尾
case，留意黄色波浪线提示 - CI 流程中加入 lint 检查，防止带漏 break 的代码合入主干
用测试暴露穿透隐患
穿透 bug 往往在边界值上爆发。一个简单测试就能提前揪出问题。
- 对每个
case单独传入对应值，验证输出是否唯一、无多余日志或副作用 - 比如传
'a'却打印了“优秀”“良好”“及格”，基本就是case 'a'少了break - 特别关注
default前的 case——它们最容易被忽略，也最容易引发连锁执行
考虑更安全的替代写法
如果你发现项目里 90% 的 switch 都是“一值一处理”，那它可能真只是 if-else 的替代品，而非必须用 switch 的场景。
- 用
Map做静态查表：如const daysInMonth = new Map([[2, 28], [4, 30], [1, 31]])，零穿透风险 - 用数组
includes判断分组：如if ([‘loading’, ‘pending’, ‘fetching’].includes(status)) { ... } - 对象字面量 + 可选链：如
handlers[status]?.()，语义清晰且天然隔离
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
