deadlock 时程序立即终止，唯一线索是 panic 末尾的 goroutine 列表；需重点检查 main goroutine 是否停在 channel 操作、阻塞调用或锁等待上。
看 panic 日志里 goroutine 堆栈，不是“哪行报错”，而是“谁在等什么”
热路径上一旦出现 fatal error: all goroutines are asleep - deadlock!，说明运行时已确认所有 goroutine 永久阻塞，程序立刻终止——没有“卡顿缓冲期”，也没有重试机会。此时唯一可信线索就是 panic 末尾打印的 goroutine 列表。
重点扫三类信息：
-
maingoroutine 停在ch 、<code>、<code>wg.Wait()或mu.Lock()？这直接暴露热路径入口点 - 其他 goroutine 是否全卡在同一个 channel 操作（如全部
runtime.chansend）？说明热路径中存在单点收发失配 - 有没有 goroutine 卡在
select {}或空for {}？这不是资源争用，但会触发死锁 panic，常见于热路径里的兜底逻辑没设退出条件
查无缓冲 channel 在热路径中的收发是否成对且有关闭方
热路径里用 make(chan int) 而非 make(chan int, 1) 是高危信号。无缓冲 channel 要求发送和接收**同时就绪**，稍有延迟就阻塞；而热路径往往并发密集、时序敏感，极易暴露问题。
典型错误模式：
- 热路径中
ch 后，接收 goroutine 尚未启动或已提前退出 - 用
for v := range ch消费，但发送方从不调用close(ch)（尤其在长生命周期服务中） - 多个热路径 goroutine 共用一个 channel，但关闭逻辑分散在不同函数中，导致
close被重复调用或遗漏
验证方式：在 panic 日志里搜 chan send 和 chan recv，若一边全满、另一边全空，基本锁定是热路径中 channel 使用失衡。
盯 sync.RWMutex 在热路径中的读锁重入与锁升级
热路径常做高频读操作，容易滥用 sync.RWMutex.RLock()。但 Go 不支持读锁升级为写锁，也不允许同一 goroutine 多次 RLock() —— 这种“看似只读”的调用，在热路径中因调用链嵌套极易触发隐式死锁。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
常见场景：
- 热路径 A 函数调用
rwMu.RLock()读缓存，中间调用 B 函数，B 又调用了rwMu.Lock()更新数据 - 热路径中起 goroutine 异步上报指标，该 goroutine 内部又尝试
rwMu.RLock()，而主线程仍持有读锁
表现是：panic 日志里多个 goroutine 卡在 (*RWMutex).RLock 或 (*RWMutex).Lock，pprof 显示大量 runtime.gopark 等待。修复不是加锁粒度拆分，而是确保每个 goroutine 对同一把 RWMutex 最多一次 RLock() + 一次 RUnlock()，且绝不混用读写锁调用。
用 go tool trace 回放热路径 goroutine 状态变迁
panic 日志只能告诉你“谁卡住了”，trace 才能告诉你“怎么卡住的”。热路径死锁往往发生在毫秒级时序偏差下，仅靠堆栈无法还原竞争过程。
实操步骤：
- 启动前加
import _ "net/http/pprof"，main开头起 HTTP server：go http.ListenAndServe("localhost:6060", nil) - 复现问题后执行：
go tool trace http://localhost:6060/debug/trace?seconds=5 - 打开 Web UI → “Goroutine” 标签页 → 筛选状态为
chan recv或chan send的 goroutine
关键线索：某个热路径 goroutine 长时间处于 chan recv，且对应 sender 始终未被调度唤醒；或两个 goroutine 在 trace 时间线上反复交替尝试获取同一把锁，但始终无法完成配对——这就是热路径中真实发生的死锁源头。
注意：无缓冲 channel 在 trace 中阻塞更明显；带缓冲 channel 可能只是“暂时满/空”，需结合热路径逻辑判断是否真死锁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
