goroutine卡在channel接收上最常见的原因是：无缓冲channel发送方与接收方未同时就绪，或所有非nil case均阻塞且无default导致永久挂起；nil channel在select中被忽略而非报错。
goroutine卡在channel接收上怎么破
goroutine无限等待最常见的原因，就是 select 或 操作阻塞在无缓冲 channel 上，且发送端永远不发、或已退出。没有超时、没有关闭通知、没有退出路径，它就真的一动不动了。
解决核心就一条：**所有可能阻塞的 channel 操作，必须有明确的退出条件**。不能依赖“理论上对方会发”，得写死“等多久/谁来关/有没有备选路径”。
- 用
select+time.After加超时，比如case - 配合
context.Context的Done()通道，尤其适合带取消语义的长期 goroutine（如 HTTP handler、后台任务） - 发送端关闭 channel 后，接收端可用
val, ok := 判断是否已关闭；但注意：仅关闭不等于“该退出”，还得结合业务逻辑判断 - 避免对无缓冲 channel 做单向接收——除非你 100% 控制发送端生命周期且确保必发
用 context.WithCancel 管理 goroutine 生命周期
靠时间超时只能解决“等太久”，但真正要防止无限等待，得让 goroutine 能被外部主动叫停。context.Context 是 Go 官方推荐方案，关键不是它多高级，而是它把“谁来关、怎么关、关了之后怎么清理”标准化了。
典型结构是：父 goroutine 调用 context.WithCancel 创建子 context，把 ctx 传给子 goroutine；子 goroutine 在每个可能阻塞的地方监听 ctx.Done()。
- channel 接收必须和
ctx.Done()一起进select，例如：select { case msg := - 不要只监听一次
ctx.Done()就完事——得在循环里持续监听，否则第一次没触发，后面就再没机会了 -
ctx.Err()在Done()关闭后才返回非 nil，别在select外提前检查，那没用 - 如果 goroutine 启动了其他子 goroutine，记得把同一
ctx传下去，形成取消链
range 遍历 channel 时 goroutine 不退出？
for range ch 看似简洁，但它隐含一个强假设：**channel 一定会被关闭，且关闭前所有值都已发送完毕**。一旦发送端 panic、忘记 close、或根本没打算关，这个 for 就永远卡在那。
这不是 bug，是设计使然。所以生产代码里，除非你完全掌控发送端（比如本地内存 channel + 明确的 close 调用），否则别单独依赖 range。
- 改用
for+select显式控制，把ctx.Done()和并列 - 如果必须用
range，确保发送端有且仅有一次close(ch)，且 close 前不再发新值（否则 panic） - 注意：
close(ch)只影响接收端，对已阻塞在的 goroutine 会立即唤醒并返回零值+<code>false；但若接收端正在select多个 case，它未必选中这个 case
sync.WaitGroup 等不到 goroutine 结束？
sync.WaitGroup 本身不防无限等待，它只是计数器。如果你 Wait() 却忘了 Done()，或者 Done() 被卡在某个 channel 操作里没执行到，那主线程就真等死了。
关键不在 WaitGroup，而在“谁负责调用 Done()”以及“Done() 是否一定能执行到”。最稳妥的做法，是把 defer wg.Done() 放在 goroutine 函数最开头。
- 永远在 goroutine 启动函数内第一行写
defer wg.Done()，而不是在逻辑末尾——防止中间 panic 或提前 return 导致漏调 - 如果 goroutine 内部有循环或长任务，
Done()应该在函数退出时调用，不是任务完成时调用（除非你明确要等任务结束） - WaitGroup 和 context 要配合用：goroutine 用 ctx 控制退出，函数末尾 defer Done，这样无论正常结束还是被 cancel，计数都能正确减掉
真正难的不是加 timeout 或写 context，而是想清楚：这个 goroutine 的退出边界到底由谁定义？是时间到了、请求取消了、数据流结束了，还是配置变了？把退出条件落到具体代码里，比套模板重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
