break是switch语句中控制流程的关键，漏写会导致fall-through；仅在有意共享逻辑时省略break，default也应统一加break，推荐启用ESLint no-fallthrough规则。
在 JavaScript 的 switch 语句中，break 不是可有可无的语法糖，而是控制执行流程的关键开关。漏写 break 会导致“穿透”（fall-through）——程序会继续执行下一个 case 分支，哪怕其条件不匹配。
break 决定是否终止当前 case 的执行
每个 case 块运行完后，若没有 break，JS 引擎不会自动跳出 switch，而是顺次执行后续所有 case 中的语句，直到遇到 break、return、抛出异常，或整个 switch 结束。
- ✅ 正确写法（带 break）：
<code>
let day = 2;
switch (day) {
case 1: console.log("周一"); break;
case 2: console.log("周二"); break;
case 3: console.log("周三"); break;
default: console.log("无效日期");
}
</code>
→ 输出仅："周二"
- ❌ 漏掉 break 的后果：
<code>
case 2: console.log("周二");
case 3: console.log("周三");
default: console.log("无效日期");
</code>
→ 输入 day = 2 时，输出："周二"、"周三"、"无效日期" —— 明显逻辑错误。
不加 break 的合理使用场景有限但真实存在
穿透行为本身不是 bug，而是一种设计特性。只有在**有意让多个 case 共享同一段逻辑**时，才应省略 break。
- 例如：将多个值映射到相同操作
<code>
switch (key) {
case "Enter":
case " ":
case "\t":
handleSubmit();
break; // 只在共享逻辑结束后加一次
}
</code>
这种写法简洁且意图明确，但必须配合注释或团队规范，避免误读。
立即学习“Java免费学习笔记（深入）”；
default 位置与 break 同样重要
default 并不天然“终结” switch。如果它位于末尾但没写 break，虽无后续 case 可穿透，但若 default 后面还有代码（比如在 switch 外部），不影响；然而若 default 在中间，漏 break 仍会穿透到下一个 case。
- 推荐始终为
default加break，保持风格统一，降低维护风险 - 现代 linter（如 ESLint）通常会警告缺失的
break，建议启用no-fallthrough规则
替代方案：用 if-else 或对象映射提升可读性
当 case 数量多、逻辑复杂，或需要类型转换/范围判断时，强行用 switch 反而增加出错概率。此时可考虑：
- 用
if-else if-else显式表达条件边界 - 用对象字面量或
Map实现值到函数的映射，天然规避穿透问题 - TypeScript 用户还可借助联合类型 + 类型守卫获得更安全的分支处理
switch 的优势在于等值比较的清晰性和引擎优化潜力，但前提是结构严谨——而 break 就是那根承重梁。
