无缓冲通道死锁不是“卡住”，是 panic 立即发生：Go 运行时检测到所有 goroutine 全部阻塞且无法唤醒时，立即抛出 fatal error: all goroutines are asleep - deadlock! 并终止程序，panic 日志即第一现场。
无缓冲通道死锁不是“卡住”，是 panic 立即发生
Go 运行时一旦检测到所有 goroutine 全部阻塞且无法唤醒，会立刻抛出 fatal error: all goroutines are asleep - deadlock! 并终止程序。这不是延迟响应或超时问题，而是运行时强制中断——意味着你看到的 panic 日志就是第一现场，不是事后线索。
关键判断点：如果 panic 中只出现 1 个 goroutine（通常是 main），且堆栈停在 c 或 <code> 行，基本可断定是单 goroutine 内对无缓冲通道的自同步失败。
- panic 日志里列出的 goroutine 状态（如
goroutine X [chan send]）比代码逻辑更可信 - pprof 的
goroutineprofile 在死锁发生前可能来不及采集，别依赖它定位 - 加
log.Printf打点没用：死锁发生在语句执行瞬间，日志甚至可能根本没刷出
同一 goroutine 里先发后收必死锁，哪怕只差一行
无缓冲通道要求发送与接收“同时就绪”，不是“先后执行”。下面这段代码看似合理，实则必然死锁：
c := make(chan int) c <- 42 // 阻塞在此，永不继续 n := <-c // 永远执行不到 fmt.Println(n)
原因很简单：c 是同步阻塞操作，必须有另一个 goroutine 正在执行 <code> 才能完成；而当前 goroutine 卡死在这里，根本走不到下一行。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 哪怕把
放在 <code>defer或if分支里，只要没在另一个 goroutine 中提前启动，就无效 - 用
select包一层也救不了：select { case c 同样阻塞，因为没有接收方 - 唯一解法是让发送和接收落在**不同 goroutine**，哪怕只是用
go func() { c
多个 channel 串联时，死锁常藏在“接收者没轮回来”
典型场景：A → B → C 三级通道转发，其中 B 和 C 都是无缓冲通道。常见错误是把整个链路塞进一个 goroutine：
func handler(in <-chan []byte, out chan<- string) {
for m := range in {
result := process(m)
out <- result // ❌ 死锁高发点：out 无缓冲，但调用方没在 select 中监听它
}
}问题在于：主 goroutine 发送完 in 后，进入 handler 执行 out ，此时若主 goroutine 还没回到 <code>case 分支，<code>out 就永远阻塞。
- 不能靠
len(ch) == 0判断无缓冲通道是否“空”——它的长度恒为 0，这个判断毫无意义 -
select加default只是跳过发送，不解决数据丢失或逻辑断裂问题 - 真正可靠的做法是：确保每个无缓冲通道的两端，分别由**独立且持续运行的 goroutine** 控制
sync.RWMutex 读锁重入是隐性死锁，和 channel 无关但症状相似
panic 日志显示大量 goroutine 卡在 (*RWMutex).RLock 或 (*RWMutex).Lock，且堆栈里反复出现同一函数调用自身 RLock，大概率是读锁重入：
func cacheGet(key string) string {
mu.RLock()
defer mu.RUnlock()
if val, ok := cache[key]; ok {
go func() { // 新 goroutine
mu.RLock() // ❌ 同一把锁，在另一 goroutine 里再次 RLock
defer mu.RUnlock()
log.Printf("hit %s", key)
}()
return val
}
return ""
}Go 标准库明确禁止对同一 sync.RWMutex 在不同 goroutine 中多次调用 RLock()，这会破坏内部计数器，导致后续所有 Lock/RLock 永久挂起。
- 这种死锁不会触发
all goroutines are asleep，但表现类似：goroutine 堆栈停滞、CPU 归零、服务无响应 - 用
go-deadlock替换sync包可在测试阶段提前暴露该问题 - 修复不是“加更多 goroutine”，而是严格遵循“每个 goroutine 对同一 RWMutex 最多一次 RLock + 一次 RUnlock”
死锁最麻烦的地方不在发现，而在它总发生在你认为“已经配对好”的地方——比如以为 for range 会自动退出，却忘了 close；或者以为 select 已覆盖所有 case，却漏掉某个通道永远没人关。真实系统里，channel 和 mutex 的死锁往往交织出现，得盯着 panic 堆栈里每一行 goroutine 的状态，而不是只看自己写的那几行逻辑。
