goto仅限同一函数内跳转，用于错误后集中清理资源；不可跨函数、跨作用域或跳入变量声明块；标签须预先声明且区分大小写；禁用模拟循环或条件分支。
goto 只能在同一个函数内跳转
Go 语言的 goto 不支持跨函数、跨作用域跳转，标签必须和 goto 语句在同一个函数里，否则编译直接报错：goto label jumps into block 或 undefined label。
常见错误是想用 goto 跳出多层循环或提前结束 defer 链——这不行。它只能跳到当前函数内已声明的标签，且不能跳进任何变量声明的作用域（比如不能跳进 if 或 for 块内部再声明新变量的地方）。
- 标签名后跟冒号，例如：
cleanup:，不能带空格或括号 - 标签必须有对应语句（哪怕只是
;），不能悬空 - 跳转目标行不能是变量短声明
:=的位置，否则编译失败
清理资源时 goto cleanup 是合理用法
Go 没有 try/finally，但多个 defer 的执行顺序是后进先出，有时反而不方便——比如打开文件、申请内存、初始化锁，任一失败都要按反序释放。这时用 goto cleanup 更直白可控。
典型场景：函数开头做一堆可能失败的初始化，中间任意一步出错就统一收尾。
立即学习“go语言免费学习笔记（深入）”；
func process() error {
f, err := os.Open("x.txt")
if err != nil {
goto cleanup
}
buf := make([]byte, 1024)
n, err := f.Read(buf)
if err != nil {
goto cleanup
}
// ... 成功逻辑
return nil
cleanup:
if f != nil {
f.Close()
}
return err
}
- 所有 cleanup 相关代码集中写在函数末尾，可读性不差
- 注意：
f和err必须在goto之前声明（用var f *os.File或f := (*os.File)(nil)），否则跳过去会访问未定义变量 - 不要用它替代正常错误处理流程，仅限“一次性集中释放”这种明确模式
别用 goto 模拟循环或条件分支
用 goto 写 while 或嵌套判断，代码立刻难维护，而且 Go 编译器不会优化这类写法，性能没优势，还容易漏 break、跳错位置。
错误示例：start: → 条件判断 → goto start；或者一堆 goto a/goto b 替代 switch。
- Go 官方明确建议：仅用于错误处理后的清理跳转
- 静态分析工具（如
golint）会警告非 cleanup 场景下的goto - 协程（goroutine）里用
goto不影响调度，但会让 stack trace 更难追踪
标签名作用域和大小写敏感
标签名不是变量，不参与作用域查找，但它区分大小写，且只在当前函数生效。同名标签在不同函数里互不影响，但在同一函数里重复定义会编译失败：label redefined。
- 标签名不能和变量、函数、包名冲突？不强制，但强烈建议避免——比如别叫
return:或main: - IDE 通常不识别标签跳转，所以重构时容易漏改，靠人眼检查
- 如果函数很长，标签离
goto太远，阅读时得滚动查找——这是最常被忽略的可维护性成本
goto 真正省事的地方只有一个：把散落在各处的 Close、Free、Unlock 收拢到一块。别的地方它几乎都在制造麻烦。 
