go模块依赖本身不会导致运行时死锁崩溃，fatal error: all goroutines are asleep - deadlock! 是runtime对goroutine状态的终局判决，只发生在运行期，与go mod、go.sum或import循环无关；import循环会在编译阶段被拒绝，根本无法进入运行时。
Go模块依赖本身不会导致运行时死锁崩溃——你看到的 fatal error: all goroutines are asleep - deadlock! 和 go mod、go.sum 或 import 循环完全无关。那是 runtime 对 goroutine 状态的终局判决，只发生在运行期，和编译期的依赖解析是两层事。
为什么 import 循环不等于运行时死锁
Go 编译器在构建阶段就拒绝 import 循环（如 A → B → A），报错 import cycle not allowed，根本跑不到 runtime 阶段。所以如果你遇到 deadlock panic，问题一定出在 goroutine 协作逻辑里，不是模块路径写错了或 go.mod 里多了个 replace。
- 模块依赖图是静态的、有向无环图（DAG），Go 工具链强制保证这点
- runtime 的 deadlock 检测只看 goroutine 是否全部 park 在 channel/mutex/WaitGroup 上，不读
go.mod - 常见误判：把
go build卡住（比如 proxy 不通、vendor 缺失）当成死锁 —— 那是构建阻塞，不是程序 panic
真正容易被当成“模块死锁”的三种运行时场景
这些现象常出现在依赖了第三方库的项目中，但根因仍是并发逻辑缺陷，不是模块本身：
-
db.Query()+rows.Next()未 close，再调db.Exec()→ 连接池耗尽，所有 goroutine 卡在db.connPool.getConn() - 第三方 SDK 内部用了未关闭的无缓冲
chan，且没暴露关闭接口 → 你的调用方 goroutine 卡在 - 某个库的初始化函数里启动了 goroutine 并向内部 channel 发送，但没配对接收者（比如忘了调
sdk.Start()）→ 主 goroutine 卡在sdk.Init()返回前
排查时盯死这三行日志线索
一旦 panic 出现，立刻看 stack trace 里每个 goroutine 停在哪，而不是翻 go.mod：
- 停在
runtime.gopark+chan.send或chan.recv→ 检查 channel 收发配对和关闭时机 - 停在
sync.runtime_SemacquireMutex→ 查锁顺序是否一致，有没有 defer 忘 unlock - 停在
database/sql.(*DB).conn或runtime.nanosleep→ 怀疑连接池或 WaitGroup 未 Done
模块依赖管理再复杂，也不会让 goroutine 睡过去；真正让程序“全睡着”的，永远是你代码里那几行没配对的 ch 、没释放的 <code>mu.Lock()、或没 close 的 rows。别在 go.mod 里找 runtime 的 bug。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
