Fall-through 是 Java switch 的默认行为：匹配 case 后不自动终止，而是顺序执行后续所有 case 代码，直至遇到 break、return、throw 或 switch 结束；它是有意设计，用于多值共享逻辑，非 bug。

什么是 Fall-through？

Fall-through 是 Java switch 语句的默认行为：一旦某个 case 匹配成功，程序会从该 case 开始执行，**不会自动停止**，而是继续向下执行后续所有 case 的代码块，直到遇到 break、return、throw 或 switch 结束。

它不是 bug，而是继承自 C 语言的设计选择，目的是支持多值共享逻辑、提升底层跳转效率。case 标签本质上只是跳转标记（label），不构成作用域边界或隐式中断点。

Fall-through 常见误用场景

• 忘记写 break，导致本应独立处理的分支被意外连通
• 在 case 后添加了注释或空行，误以为已自然分隔，实际无任何控制作用
• 重构时删掉某个 case 的代码但保留标签，留下“悬空穿透”风险
• 嵌套 switch 中误判外层 break 对内层的影响（break 只作用于最近的 switch）

哪些情况适合主动使用 Fall-through？

当多个取值需要执行完全相同的逻辑时，Fall-through 是简洁且语义清晰的选择：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 工作日/周末归类：case "Mon": case "Tue": case "Wed": ... System.out.println("工作日"); break;
• HTTP 状态码分组处理：case 400: case 401: case 403: logAuthError(); break;
• 枚举状态流转：case PENDING: case PROCESSING: updateTimestamp(); // fall-through（需加注释说明）

关键前提是：这些 case 的业务含义确实一致，且后续操作是同一逻辑链的自然延续。

立即学习“Java免费学习笔记（深入）”；

安全使用的三个硬性习惯

• 每个 case 分支末尾，除非明确需要穿透，否则必须写 break（或 return/throw）
• 若有意穿透，必须在该 case 最后一行添加清晰注释，如 // fall-through 或 // Intentional fall-through
• 对复杂分支逻辑，优先考虑用 Map<K, Runnable> 或 enum + method reference 替代长 switch，规避穿透管理成本

编译器与 IDE 的辅助建议

现代 JDK（14+）和主流 IDE（IntelliJ、Eclipse）已支持检测“缺失 break”的潜在穿透，但默认不报错——需手动开启检查项：

• IntelliJ：Settings → Editor → Inspections → Java → Control flow issues → 'Fall-through in switch statement'
• Java 编译器：启用 -Xlint:fallthrough 可在编译时输出警告
• 建议将该警告升级为错误（通过 Maven 或 Gradle 配置 compilerArgs），强制团队统一规范