Go官方唯一明确鼓励goto的场景是错误清理，须同时满足：资源必须在goto前声明、标签须在同一作用域层级、跳转目标后不能为空行。
用 goto 做错误清理时的三个硬约束
这是 Go 官方文档唯一明确鼓励 goto 的场景，但必须同时满足三个条件，否则不如老老实实写重复的 close/free 代码。
- 所有资源（
f,conn,mu等）必须在goto标签之前声明，不能用:=在跳转路径之后才定义——否则编译报错goto jumps over declaration -
cleanup:标签必须和goto cleanup在同一函数、同一作用域层级，不能藏在if或for块内部，否则触发goto jumps into block - 跳转目标行不能是空悬的，哪怕只写一个分号
;也得有——cleanup:后面直接跟return或if f != nil { f.Close() }都合法，但cleanup:单独一行会编译失败
用 goto 跳出多层循环时，为什么 break label 更推荐
Go 支持带标签的 break，它和 goto 都能跳出嵌套循环，但语义和限制完全不同。
-
break outer只终止循环本身，不跳过中间的defer或变量作用域检查；goto outer则可能绕过defer，导致文件没关、锁没释放 -
outer:必须紧贴最外层循环（如outer: for i := range data { ... }），而goto标签可以放在任意位置，容易误放成if true { outer: ... }导致编译失败 - 调试器对
break label的跟踪更稳定；goto在 stack trace 中可能显示为“跳转丢失上下文”，尤其在协程中
goto 跳转后访问变量的常见崩溃点
这不是运行时 panic，而是编译期直接拒掉——Go 编译器对变量生命周期检查非常严格。
- 不能跳过
:=短声明：比如goto L; x := 42; L: fmt.Println(x)会报错，必须提前用var x int - 不能跳进
if或for块：即使块内没声明新变量，只要语法上属于子作用域，goto就不被允许 - 标签名不能和变量/函数同名：比如已有
var cleanup bool，再写cleanup:会导致编译器混淆，报undefined label或更奇怪的解析错误
什么时候该放弃 goto，改用其他方式
一旦出现以下任一情况，说明控制流已经超出了 goto 的合理承载能力。
立即学习“go语言免费学习笔记（深入）”；
- 函数里出现两个以上不同目的的
goto（比如一个goto cleanup，一个goto retry，一个goto fallback）——这基本等于在手写状态机，该抽成独立函数了 - 清理逻辑需要根据错误类型做分支处理（如
os.IsNotExist(err)和os.IsPermission(err)要走不同路径），goto无法携带参数，强行硬编码会让后续维护者抓狂 - 函数里混用了
defer和goto：只要有一处goto跳过了已注册的defer，资源泄漏风险就从“可能”变成“必然”
cleanup: 块里漏掉了 mu.Unlock()，而因为所有错误路径都靠 goto 汇入这里，这个 bug 会静默影响所有调用点。 
