Go的fallthrough是强制跳转到下一case并忽略其条件判断，仅能穿透一层且必须位于块末尾；它不等价于C/Java的隐式贯穿，也不支持多层穿透或与break共存。
fallthrough 会跳过下一个 case 的条件判断
Go 的 fallthrough 不是“继续执行后续分支”，而是强制跳转到紧邻的下一个 case 语句块，**完全忽略它的条件表达式**。这点和 C/Java 的 break 缺失行为不同——它不依赖“条件为真”，只做无条件跳转。
常见错误现象：fallthrough 写在最后一个 case 后，导致编译失败（cannot fallthrough final case in switch）；或误以为它能穿透多个分支，实际只能穿透一层。
- 必须紧跟在
case或default块末尾，不能加任何语句（包括空行、注释也不行） - 目标
case必须存在且非末尾，否则编译报错 - 如果下一个
case是default，也能穿透过去，但要注意default没有表达式可跳过
switch x {
case 1:
fmt.Println("one")
fallthrough // ✅ 穿透到 case 2
case 2:
fmt.Println("two") // 即使 x != 2，也会执行
default:
fmt.Println("other")
}
什么时候该用 fallthrough，而不是重复写逻辑
典型场景是多个离散值需要共享同一段处理逻辑，且这些值在语义上具有自然分组关系，比如状态码归类、协议版本兼容、权限位组合。
反例：用 fallthrough 模拟 if-else 链（如 case 1: fallthrough; case 2: fallthrough; case 3:），不如直接用 if x == 1 || x == 2 || x == 3 清晰。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐用于枚举值分组：比如 HTTP 状态码
case 200, 201, 204:已足够，无需fallthrough；但若 201 和 204 后续要额外打日志，而 200 不需要，才考虑拆开 +fallthrough - 避免在含
return、panic或os.Exit的case后写fallthrough，会触发 unreachable code 报错 - 注意变量作用域：每个
case是独立作用域，fallthrough过去后无法访问前一个case中声明的局部变量
fallthrough 和 break 的配合容易出错
Go 默认每个 case 自动隐式 break，所以显式写 break 只在两种情况有用：跳出多层 switch（带 label），或提前终止当前 case 执行但不穿透。
常见错误现象：在用了 fallthrough 的 case 里又写了 break，结果 break 生效了，fallthrough 被跳过——因为 fallthrough 必须是该块最后一条语句。
-
fallthrough和break互斥，不能共存于同一case块末尾 - 想实现“满足条件时穿透，否则跳出”，得用嵌套 if，不能靠
fallthrough+break组合 - 带 label 的
break不影响fallthrough行为，但会让代码意图变模糊，慎用
编译器不会帮你检查 fallthrough 的逻辑合理性
Go 编译器只校验 fallthrough 的语法位置和目标存在性，不管语义是否合理。比如把 case "GET": 后 fallthrough 到 case "POST":，即使两者毫无关联，也能通过编译。
这意味着：维护者必须人工确认穿透路径的业务意义，CI 或 linter 很难覆盖这类逻辑漏洞。
- git blame 查到某处加了
fallthrough，大概率意味着那里改过需求，值得顺手看一眼上下文 - 如果多个
case共享大量逻辑，优先提取成函数，比靠fallthrough串联更易测、易读 - 测试时别只覆盖单个
case输入，要专门构造穿透路径的输入，验证是否真的执行了预期的组合逻辑
最麻烦的不是语法写错，而是半年后你看着两个被 fallthrough 粘在一起的 case，不确定当初是因为性能妥协，还是漏删的调试残留。
