Go 的 fallthrough 强制进入紧邻的下一个 case 分支体，不判断条件，仅限末尾使用且不可跨多个 case；推荐用逗号分隔多值 case 替代。
fallthrough 会跳过下一个 case 的条件判断
Go 的 fallthrough 不是“继续执行下一条语句”，而是强制进入**紧邻的下一个 case 分支体**，哪怕那个 case 的条件根本不满足。这是最常被误解的一点——它不看值、不比条件、不走逻辑，纯属“硬跳”。
常见错误现象：fallthrough 放在最后一个 case 里，编译直接报错 cannot fallthrough final case in switch；或者误以为它能跨多个 case 跳转（实际只跳一个）。
- 必须写在
case末尾，且后面不能有其他语句（包括空行也不行） - 目标 case 必须存在，且不能是
default（fallthrough到default合法，但default后不能再fallthrough） - 如果下一个 case 是空分支（只有
fallthrough），会继续往下跳，直到遇到非空分支或结束
什么时候真需要 fallthrough？不是为了“省代码”
真正合理的使用场景极少，典型的是**范围型枚举归类**，比如把多个离散值映射到同一处理逻辑，又不想重复写代码块。但注意：这不是替代 if-else 的快捷方式，更不是为了“看起来连续”。
错误用法示例：用 fallthrough 模拟 C 风格的“漏掉 break 导致串行”，结果逻辑失控；或在涉及变量赋值/作用域的 case 中滥用，导致未定义行为。
立即学习“go语言免费学习笔记（深入）”；
- 推荐仅用于常量分组，如
http.StatusNotFound、http.StatusGone都走同一错误日志路径 - 避免在带
:=声明变量的 case 中使用fallthrough，因为变量作用域不会延续到下一个 case - 如果两个 case 处理逻辑高度相似，优先考虑抽函数，而不是靠
fallthrough硬连
switch status {
case http.StatusNotFound:
log.Println("not found")
fallthrough
case http.StatusGone:
cleanupCache() // 这里能访问到上个 case 的变量吗？不能。status 是参数，但其他局部变量不行。
}
fallthrough 和 break、return 的协作关系
fallthrough 和 break 是开关两端：前者强制向下穿透，后者强制跳出整个 switch。它们不能共存于同一 case（语法错误），但可以出现在不同分支中。关键在于：一旦用了 fallthrough，你就放弃了对该分支边界的控制权。
容易踩的坑是混用 return 和 fallthrough —— return 会让函数提前退出，fallthrough 就根本没机会执行；反过来，如果在 fallthrough 后的 case 里写了 return，前面的 fallthrough 就成了“单程票”，无法回退。
- 不要在
fallthrough前加return或break，否则fallthrough成为死代码 - 如果某个 case 既想记录日志又想终止流程，别写
fallthrough再return，直接在当前 case 里做完所有事 -
break LABEL可以跳出多层 switch，但它对fallthrough无影响——fallthrough只关心当前 switch 的下一个 case
替代 fallthrough 的更清晰写法
绝大多数声称“需要 fallthrough”的场景，其实用逗号分隔多个 case 值更安全、更易读。Go 允许一个 case 后跟多个条件值，语义明确，无副作用，还不用担心作用域或顺序问题。
性能上毫无差别，但可维护性高得多。尤其当团队里有人不熟悉 fallthrough 的穿透机制时，逗号写法几乎不会出错。
- 把
case 1: fallthrough; case 2:改成case 1, 2: - 如果逻辑差异大，宁可复制几行代码，也不要靠
fallthrough把不同语义绑在一起 - 工具链（如
go vet）不会检查fallthrough的合理性，但会提醒你重复的 case 值——而逗号写法天然支持这种检查
switch mode {
case "dev", "staging": // 清晰、安全、符合直觉
enableDebug()
case "prod":
disableTracing()
}
fallthrough 的真实复杂点不在语法，而在它打破了 switch 的默认隔离契约。只要有一个 case 用了它，整段 switch 的执行流就不再是“匹配即止”，后续每个 case 都得重新审视是否会被意外穿透——这点很容易在代码演进中被遗忘。
