死锁根本原因是所有goroutine均阻塞且无人可唤醒，运行时直接panic；for range ch卡死主因是通道未关闭，无缓冲channel收发必须同步就位。
Go并发编程中发生死锁，根本原因只有一个：所有goroutine都阻塞在同步原语上，且无人能唤醒它们。这不是程序“慢了”，而是运行时直接 panic 报错：fatal error: all goroutines are asleep - deadlock!。它不靠竞态检测触发，也不依赖超时——只要调度器发现没有一个 goroutine 处于 runnable 状态，就立刻终止程序。
为什么 for range ch 会卡死？——通道未关闭是最常见诱因
当你写 for v := range ch { ... }，Go 实际执行的是“持续接收直到 ch 被关闭”。如果没人调用 close(ch)，这个循环就永远等下去。
- Walk 递归遍历完树后不会自动关 channel，这是设计使然（避免多处 close 引发 panic）
- 主 goroutine 卡在
range ch1，而发送 goroutine 已退出，ch1永远没被 close → 无其他 goroutine 可推进 → 死锁 - 哪怕只漏关一个 channel（比如只关
ch1没关ch2），只要主逻辑还依赖另一个未关的 channel，照样死锁
向无缓冲 channel 发送却没人收，是“秒级死锁”
无缓冲 channel 的收发必须“同时就位”。下面这段代码运行即死锁：
func main() {
ch := make(chan int)
ch <- 1 // 阻塞：主 goroutine 在这里挂起
}- 没有其他 goroutine 启动并执行
，发送操作就永远无法完成 - 带缓冲 channel（如
make(chan int, 1)）可暂存数据，但缓冲区满后仍会阻塞，本质相同 - 解决思路不是“加缓冲”，而是明确通信契约：谁发、谁收、何时收完
锁嵌套顺序不一致，是隐蔽的死锁温床
两个 goroutine 分别按不同顺序获取两把互斥锁，极易形成循环等待：
go func() {
mu1.Lock()
time.Sleep(10 * time.Millisecond)
mu2.Lock() // 等 mu2
mu2.Unlock()
mu1.Unlock()
}()
go func() {
mu2.Lock()
time.Sleep(10 * time.Millisecond)
mu1.Lock() // 等 mu1 → 死锁！
mu1.Unlock()
mu2.Unlock()
}()- goroutine A 持
mu1等mu2，B 持mu2等mu1 - 这种死锁不会被
go run -race捕获，因为不涉及数据竞争，只涉及逻辑等待 - 预防方法：全局约定锁获取顺序（如总是先
mu1后mu2），或改用 channel 通信代替共享内存
真正难排查的不是“明显卡住”的场景，而是那些看似合理、实则缺少退出条件的循环——比如用 select {} 等待多个 channel 却忘了关其中任何一个，或者用 sync.WaitGroup 但 Done() 调用次数少了一次。死锁从不预告，它只在所有路都被堵死时，才亮出那行红色错误。
