不写 break 会导致 case 穿透——程序从匹配 case 起顺序执行后续所有 case 和 default 代码，直至遇到 break、return、throw 或 switch 结束；穿透是确定行为，非随机错误，因 javascript 将 case 视为跳转标签而非逻辑隔离块。
不写 break 会导致“case 穿透”（fall-through）——程序不会在匹配的 case 结束，而是继续执行后续所有 case 和 default 中的代码，直到遇到 break、return、throw 或 switch 块自然结束。
穿透是确定行为，不是随机出错
JavaScript 把每个 case 当作跳转标签，不是逻辑隔离块。一旦跳进 case 'A'，就从那行开始顺序执行，完全不重新比对后面 case 的值。哪怕 case 'B' 对应的条件根本不符合当前输入，只要没 break，照样执行。
- 输入
'apple'，却同时触发'apple'、'banana'、'orange'三段逻辑 - 用户点“保存”，控制流没停住，顺带执行了“删除”和“退出”操作
-
default不是保险丝——它前面的case没 break，照样被卷进去执行
实际影响远超多打几行日志
业务代码通常带副作用，穿透会让这些副作用被意外重复或错序触发：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 数据库插入一次 → 又插一次 → 主键冲突或数据重复
- 调用支付接口 → 接着又调用退款接口 → 资金异常变动
- 权限检查通过 → 没中断 → 后续高危操作被无条件执行
- 文件打开一次 → 再打开一次 → 句柄泄漏或内容覆盖
调试时很难第一时间定位
现象和根源脱节：编译器不报错，控制台只显示“多输出了几行”，但没人会立刻想到是 switch 漏了 break。
- 日志分散在不同模块，时间戳紧挨着，却来自四个不相关的
case - 状态变化延迟显现，比如界面刷新后用户被登出 + 缓存清空 + 数据上报全发生
- 开发者容易先怀疑异步、并发或数据源问题，绕开
switch本身排查
有意穿透必须显式声明
虽然语言允许穿透（例如多个值共享同一段处理逻辑），但现代实践要求必须明确标注意图：
- 加注释：
// fall through或// intentional - TypeScript 或较新环境可使用
[[fallthrough]]（需配置支持） - 否则 IDE 和 ESLint（如
no-fallthrough规则）会当作潜在缺陷警告 - 建议把这类警告升级为编译/构建错误，从源头拦截疏忽
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
