最隐蔽的死锁类型是跨包初始化顺序依赖导致的隐式阻塞：init中启动goroutine、使用sync.once、replace模块或第三方库异步操作，均可能因环形依赖卡在runtime.gopark，引发deadlock panic。
init函数里启动goroutine并等待其他包init完成
这是最隐蔽的死锁类型：不涉及channel、mutex或WaitGroup，但panic日志里会出现多个init调用栈，且goroutine卡在runtime.gopark——本质是跨包初始化顺序依赖导致的隐式阻塞。
典型场景是A包的init启动一个goroutine去等B包的某个全局变量就绪，而B包的init又依赖A包的某个函数返回值。Go的包初始化是单线程、按依赖拓扑序执行的，一旦形成环，就会卡死在第一个未完成的init里。
- 现象：程序启动即panic，错误仍是
fatal error: all goroutines are asleep - deadlock!，但堆栈里看不到channel或锁操作，只有init和runtime.gopark - 定位方法：加
GODEBUG=schedtrace=1000运行，若第一秒就出现goroutines: 1且runnable: 0，基本可断定卡在init阶段 - 修复原则：init函数必须是纯同步、无goroutine、无channel操作、不调用外部包未初始化完成的函数；所有异步逻辑（如启动监听、预热缓存）应推迟到
main()或显式初始化函数中
sync.Once.Do里调用依赖本包未完成init的函数
sync.Once.Do常被误用在init阶段做“懒初始化”，但它内部会阻塞等待其他goroutine完成——如果那个函数本身又间接依赖当前包还未走完的init流程，就会形成闭环等待。
比如：A包定义了var once sync.Once; var cache = make(map[string]int)，在init()里调用once.Do(initCache)，而initCache()里调用了B包的B.GetConfig()，但B包的GetConfig()又依赖A包的某个全局变量——此时once.Do会park住当前goroutine，而整个init链无法推进。
- 关键线索：panic堆栈中出现
(*Once).Do+runtime.gopark+ 多个包名交叉出现在调用链 - 不要在init里用
sync.Once做任何跨包调用；若必须延迟初始化，改用func init() { go func() { ... }() }把逻辑彻底移出init上下文 - 用
go list -f '{{.Deps}}' your/package检查包依赖图，确认是否存在A→B→A的循环依赖
go.mod replace指向未完成初始化的本地模块
当用replace将公共模块替换成本地开发分支时，如果该本地模块自身有init副作用（如注册全局handler、初始化数据库连接池），而主模块的init又依赖它，就可能因加载顺序错乱触发死锁。
Go 1.21+对replace模块的初始化时机没有保证：它可能比主模块早、也可能晚，尤其当replace路径包含相对路径（如./local-foo）时，模块加载器可能将其视为独立根模块，导致init执行时序不可控。
- 现象：本地调试正常，CI构建失败；或仅在
go run时出问题，go build后运行正常 - 临时规避：删掉
go.mod里的replace，改用go install -mod=readonly验证是否真由replace引发 - 长期方案：把所有带init副作用的逻辑封装进显式
Init()函数，主模块在main()开头统一调用，彻底解除对模块加载顺序的依赖
第三方库的init启动goroutine并等待context超时
某些SDK（如老版本gocql、mongo-go-driver）会在init里启动后台goroutine做连接探测或心跳，同时设置一个context.WithTimeout等待初始化完成。如果主模块的init恰好在该context deadline前还没跑完，goroutine会一直park，最终拖垮整个init链。
这不是代码bug，而是设计缺陷：init阶段不该引入任何需要等待的异步操作。
- 排查方式：用
go tool trace抓启动过程，看是否有goroutine在runtime.chanrecv或runtime.timerProc上长期park - 解决方案不是升级库（很多库至今未修复），而是提前在
main()里调用其Initialize()或Connect()方法，绕过init路径 - 永远不要信任第三方库的init——把它的文档里写着“自动初始化”的功能，全部当成手动初始化来用
真正难处理的不是channel发不出去、锁拿不到，而是init阶段那些看不见摸不着的依赖环。它们不会报错，只会在你最意想不到的时候让程序静默卡死。只要init函数里出现go、make(chan)、sync.Once或任何跨包函数调用，就要立刻警觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
