go通道死锁源于生命周期管理错误而非并发竞态；常见原因是for-range未关闭通道、多goroutine发送时未用waitgroup同步close、循环变量捕获错误导致goroutine提前退出。
Go 通道本身不产生竞态，死锁从来不是“高并发下通道竞态导致”的——那是对问题根源的误判。真正触发 fatal error: all goroutines are asleep - deadlock! 的，几乎全是通道生命周期管理错误或同步逻辑断裂，和“并发量高低”无关。并发只是让缺陷更快暴露。
for-range 遇到未关闭的通道必死锁
这是最常见、最直白的死锁来源。只要 for c := range ch 在跑，而发送方 goroutine 已退出、又没调 close(ch)，main 就永远卡在接收上。
- 错误写法：
go Walk(tree.New(1), ch)启动后不关通道，for c := range ch无限等待 - 修复核心：发送端必须在所有数据发完后调用
close(ch)，且只能由发送方调用 - 注意：
close不能在已关闭的通道上重复调用，否则 panic；也不能在接收方调用
多个发送 goroutine 时，WaitGroup + close 缺一不可
当有多个 goroutine 往同一个通道发数据（比如并行遍历子树、批量处理任务），只靠单个 close 不够——你不知道谁最后发完。
- 典型错误：每个 goroutine 自己发完就
close(ch)→ 第二个close直接 panic - 正确做法：用
sync.WaitGroup计数所有发送 goroutine，主 goroutine 等它们全部Done()后，再统一close(ch) - 别把
WaitGroup当值传——必须传指针，否则计数器不共享，Wait()永远不返回
goroutine 因变量捕获提前退出，导致通道无人接收
在 for 循环里启动 goroutine 时，若直接引用循环变量（如 ch[i]），常因闭包捕获的是变量地址而非值，造成 goroutine 读错通道、panic 或立即退出。
- 现象：主 goroutine 往某个
ch[i]发数据，但对应 goroutine 实际监听的是ch[2]（i 已越界）→ 发送阻塞 → 死锁 - 修复：把循环变量显式作为参数传入，如
go func(idx int) { - 更关键的是：goroutine 不能只收一次就退出。若用
select { case x := 单次接收，它执行完就结束，后续发送必然阻塞 - 应改为循环接收：
for x := range ch[idx] { ... }或带退出控制的for { select { ... } }
死锁不是性能问题，是逻辑断点。查 all goroutines are asleep 时，先盯住所有 range 和所有 操作，确认每个通道是否被且仅被发送方关闭，确认每个接收 goroutine 是否持续存活——这才是真正要抠的细节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
