init 函数里调用 sync.Once 或启动 goroutine 容易死锁
go 的包初始化是同步、单线程执行的，所有 init 函数按依赖顺序串行跑完才结束。一旦在 init 里触发了需要等待其他 init 完成的操作，就卡住。
典型错误：在 init 中调用 sync.Once.Do，而该 Do 的函数体又间接依赖另一个尚未执行的包的 init；或者直接起 goroutine 并用 sync.WaitGroup 等待——WaitGroup.Wait 永远不会返回，因为那个 goroutine 所依赖的初始化还没开始。
- 避免在
init中做任何跨包阻塞调用，包括http.Get、database/sql.Open、sync.Once.Do（除非确定闭包内不触碰其他包的未初始化状态） - 把需延迟初始化的逻辑移到首次使用时（比如封装成函数，内部用
sync.Once），而不是塞进init - 用
go tool trace或runtime.SetBlockProfileRate配合 pprof，能快速定位卡在哪个init调用链上
循环导入导致 init 顺序不可控
Go 不允许显式循环 import，但通过空导入（_ "xxx"）或间接依赖（A→B→C→A）可能隐式形成初始化环。这时编译器会报错，但有时只在特定构建条件下暴露——比如测试时因 testmain 引入额外依赖路径。
现象是：程序启动卡住无日志、go run 无响应、或 panic 报 fatal Error: all goroutines are asleep - deadlock，且堆栈里全是 runtime.doInit 相关帧。
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -f '{{.Deps}}' .检查依赖图，再人工排查是否存在 A→B→C→A 类路径 - 重点检查
_导入的包，它们常被忽略，但其init仍会执行 - 把共享的初始化逻辑抽到独立包（如
internal/init），由主程序显式调用，避开自动 init 机制
测试文件中 init 和 TestMain 的执行时机冲突
测试包的 init 在 TestMain 之前运行，而 TestMain 又可能调用 os.Exit 或修改全局状态。如果 init 依赖某些仅在 TestMain 中 setup 的资源（比如临时目录、mock server），就会 panic 或行为异常。
常见错误现象：go test 直接 panic，报 nil pointer dereference 或 connection refused，但 go run 正常。
- 测试包的
init不能假设任何外部环境已就绪；所有依赖应延迟到TestXxx函数内初始化 - 若必须预热，改用
func TestMain(m *testing.M)，在m.Run()前做 setup，之后 cleanup - 避免在测试文件中写
init，尤其不要初始化全局变量（如var db *sql.DB），改用 test helper 函数按需创建
go build -toolexec 和 go test -exec 下 init 行为差异
当用容器化工具（如 bazel、nix）或自定义 exec 包裹 Go 构建时，init 的执行上下文可能变化：环境变量丢失、工作目录异常、甚至标准库某些 init 逻辑（如 net/http 的默认 client 初始化）被跳过或重排。
表现是：本地 go test 正常，CI 上挂起或 panic，堆栈指向 net.init 或 crypto/rand.init 内部。
- 用
strace -e trace=clone,execve,fork观察实际启动的进程链，确认是否多了一层 wrapper 导致 init 时环境缺失 - 禁用 go 的自动 init 注入：加
-ldflags="-linkmode external -extldflags '-Static'"测试是否与链接模式有关 - 关键初始化（如随机数、DNS 配置）改为主动调用，例如显式调用
rand.Seed(time.Now().UnixNano())，而非依赖math/rand的 init
init 死锁最麻烦的地方不是找不到原因，而是它不报错、不超时、不输出——你得先意识到“它可能卡在 init”，再决定从哪一层开始切片排查。