答案是程序启动卡住不panic也不继续，本质是init阶段逻辑阻塞而非运行时死锁；典型因跨包init循环等待、init中调用阻塞api（如http.listenandserve）或goroutine+waitgroup/channel同步导致初始化无法完成。
死锁现象：程序启动卡住，不 panic 也不继续
Go 中 init 函数本身不会直接导致「死锁 panic」（即 fatal error: all goroutines are asleep - deadlock!），但 init 里隐式触发的 goroutine、channel 操作或锁竞争，可能让主初始化流程无限等待。典型表现是：程序执行到某处就完全静止，main 不进入，也没有 panic 日志输出。
这不是运行时死锁检测机制能捕获的类型，而是包初始化阶段的逻辑阻塞——比如 A 包的 init 启动一个 goroutine 等待 B 包的全局变量就绪，而 B 包的 init 又反过来等 A 包某个 channel 关闭，双方都卡在初始化途中。
- 检查是否在
init中调用了http.ListenAndServe、time.Sleep或无缓冲chan 发送 - 确认有没有在
init里启动 goroutine 并用sync.WaitGroup或chan等待其完成 - 留意
import _ "xxx"引入的副作用包（如 pprof、prometheus）是否自带阻塞型init
用 go tool compile -S 查看初始化调用链
编译器生成的初始化序列是唯一可信的执行顺序依据。运行：
go tool compile -S main.go | grep -A5 -B5 "INIT\|init.*$"
输出中会列出类似 call runtime.maininit 或 call pkg/db.init 的汇编调用，按实际执行顺序排列。如果发现两个包的 init 调用之间夹着大量未解析的符号或跳转指令，说明其中某个 init 卡住了，没返回。
- 重点关注调用链中断的位置：比如
pkg/a.init出现后，下一个本该是pkg/b.init，但实际没出现——那a.init很可能没返回 - 若看到
call sync.runtime_Semacquire或call runtime.gopark出现在某个init内部，基本就是锁或 channel 阻塞了 - 这个命令不依赖运行时，纯静态分析，适合 CI 环境提前筛查
加轻量日志定位卡点
不能在 init 里用 log.Println（它依赖自身包初始化），但 fmt.Printf 是安全的。在所有可疑包的 init 开头和结尾插入：
func init() {
fmt.Printf("[init] %s start\n", "pkg/db")
// ... real logic
fmt.Printf("[init] %s done\n", "pkg/db")
}
运行程序，观察输出停在哪一行。注意：fmt.Printf 本身不保证 flush，加 \n 和短字符串可提高可见性。
- 避免在日志里拼接变量（如
fmt.Printf("port=%d", config.Port)），防止因访问未初始化变量再次 panic - 测试时用
go run -gcflags="-l" main.go禁用内联，让日志位置更准确 - 如果日志只输出
start没有done，就说明该init卡在中间某行
为什么常规 pprof 和 trace 无效
pprof 和 runtime/trace 都依赖 main 启动后才开始采集，而 init 死锁发生在 main 之前。此时 goroutine 调度器尚未 fully up，http://localhost:6060/debug/pprof/goroutine?debug=2 根本无法访问。
真正有效的手段只有两类：编译期静态分析（go tool compile -S）和启动前轻量输出（fmt.Printf）。任何试图在 init 里起 HTTP server、开 trace、写文件的操作，只会让问题更隐蔽。
最易被忽略的是：你改了一个包的 init，但忘了它被多个其他包间接 import，不同导入路径下初始化顺序可能不同——这种非线性依赖，靠单次日志很难覆盖全貌。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
