死锁 panic 一出现就该立刻停，因为 Go 运行时检测到所有 goroutine 均阻塞在 channel、mutex、wg.Wait() 等操作且无人可唤醒时，会立即触发 fatal error 并终止程序，此时继续运行只会掩盖问题根源。
死锁 panic 一出现就该立刻停，别等日志刷屏
Go 运行时一旦发现所有 goroutine 都卡在 channel receive、send、mutex lock 或 wg.Wait() 上且无人能唤醒，会立即 panic 并打印 fatal error: all goroutines are asleep - deadlock!。这不是警告，是程序已彻底停摆——此时继续运行只会掩盖问题根源。
常见误操作是加 time.Sleep(5 * time.Second) 等待并发完成，结果主 goroutine 卡住，而 worker 已提前 panic 或退出，运行时不报死锁（因仍有 runnable goroutine），但逻辑已错漏。真正要盯的是 panic 输出里的 goroutine 堆栈，不是程序是否“看起来还在跑”。
- panic 日志里如果
main停在wg.Wait()，先检查是否漏调wg.Add()或wg.Done()，尤其注意闭包中变量捕获导致的值传递（如把wg当参数传进 goroutine 却没传指针） - 若多个 goroutine 全卡在
或 <code>ch ，说明 channel 收发不匹配：要么发送方没人接收，要么接收方没启动或已退出 - 堆栈里出现
select {}或空 for 循环，基本等于“忘了加退出条件”，比如忘了 closedoneChan或没监听ctx.Done()
用 go run -race 抓竞态，不是为了防死锁而是防“假死”
竞态（race）本身不会直接触发死锁 panic，但它会让程序行为不可预测：比如两个 goroutine 同时改同一个 map，运行时可能 panic，也可能静默覆盖数据，最终导致某个 goroutine 永远等不到预期信号——表面是死锁，实则是数据错乱引发的逻辑断链。
go run -race main.go 是必须加的测试步骤，尤其在框架集成 HTTP handler、中间件、数据库连接池等共享状态模块时：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- HTTP handler 中复用 struct 实例并修改其字段（如
req.Context().Value()存临时状态），多个请求并发访问就会 race - 全局配置 map 被 init 函数初始化后，又被某个 goroutine 动态更新，没加锁就会触发 race detector 报告
- 闭包捕获循环变量：
for _, h := range handlers { go func() { h.ServeHTTP(...) }() }—— 所有 goroutine 共享最后一个h，修复方式是go func(h Handler) { h.ServeHTTP(...) }(h)
channel 缓冲与关闭时机，错一个就全卡住
无缓冲 channel 是死锁高发区，但盲目全换成带缓冲 channel 也不解决问题。关键在收发节奏和关闭责任是否清晰：
-
queueChan由主 goroutine 发送任务，dispatcher接收并分发——那它必须由主 goroutine 在发完后close(queueChan)，否则dispatcher的for job := range queueChan永不退出 -
doneChan若是无缓冲的，worker 写入前必须确保 dispatcher 正在case result := 分支等待；若用带缓冲（如 <code>make(chan int, 4)），则需确认容量 ≥ 并发 worker 数，否则第 5 个 worker 仍会阻塞 - 永远不要在多个 goroutine 中调用
close(ch)；接收方必须用v, ok := 判断关闭，不能只依赖 <code>for range ch（万一没人 close 就无限等）
调试时别只看 panic，用 go tool trace 看谁在等谁
panic 日志只能告诉你“卡在哪”，go tool trace 才能还原阻塞路径：哪个 goroutine 在等 channel，谁本该发却没发，缓冲区是否已满。
实操步骤很直接：
- 代码开头加
import _ "net/http/pprof"，并在main()里起服务：go http.ListenAndServe("localhost:6060", nil) - 运行后访问
http://localhost:6060/debug/trace?seconds=5下载trace.out - 执行
go tool trace trace.out，打开 Web UI，在 “Goroutine” 标签页筛选状态为chan send或chan recv的 goroutine，点进去看阻塞在具体哪一行ch 或 <code>
特别注意：trace 里显示某 goroutine 长时间处于 chan recv 且对应 sender goroutine 状态为 “running” 却没执行发送，大概率是 sender 卡在上游 channel 或锁上——死锁常是链式阻塞，不是单点问题。
