for range ch 卡死是因为 channel 未关闭；它仅在 channel 关闭且缓冲区（含已发送未接收值）为空时退出，与发送端是否发完或 goroutine 是否结束无关。
for range ch 卡死是因为 channel 没关，不是“没数据了”
Go 的 for v := range ch 不会在发送端“发完就停”，它只在两个条件同时满足时退出：channel 已关闭 且 缓冲区（含已发送未接收的值）完全为空。哪怕所有 goroutine 都执行完 ch 并 return，只要没人调用 <code>close(ch)，range 就一直阻塞等待——这不是延迟，是永久挂起。
常见翻车现场：
- 主 goroutine 启动 5 个 worker 往
ch发结果，自己直接for range ch，但忘了关ch - 用
sync.WaitGroup等 worker 结束，却把close(ch)写在wg.Wait()前面（此时 worker 可能还在发） - 多个 worker 都觉得自己是最后一个，各自
close(ch)→ panic: close of closed channel
不依赖 close(ch) 的安全接收方式：按数量收，不等关闭
如果你明确知道要收多少条（比如并发请求 3 个 URL，就一定有 3 个响应），根本不需要关 channel。直接用计数循环最稳：
for i := 0; i < len(urls); i++ {
resp := <-ch
fmt.Println(resp)
}
fmt.Println("I'm done")
这种写法规避了所有关闭时机问题：不关 channel、不依赖 range 语义、不会 panic、逻辑一目了然。适用于任务总数固定、发送者与接收者职责清晰的场景。
立即学习“go语言免费学习笔记（深入）”；
必须用 for range 时，谁关、何时关、怎么关
若业务逻辑天然适合 for range（比如流式处理不确定长度的数据），则关闭动作必须满足三个硬约束：
-
谁关：只能由「最后一个可能往
ch发数据」的 goroutine 关——通常是主 goroutine，在确认所有发送者已退出后 -
何时关：必须在所有发送 goroutine 完全结束（不是刚启动）之后。推荐用
sync.WaitGroup同步：wg.Wait()返回后再close(ch) -
怎么关：如果存在多个可能触发关闭的路径（比如超时 + 正常完成），用
sync.Once包一层，避免重复 close 导致 panic
错误示范：go func() { defer close(ch) }() —— 这个 goroutine 自己启自己关，但其他发送 goroutine 可能还在跑，必然 panic。
接收方永远别碰 close(ch)，也别猜 channel 是否已关
接收方代码里出现 close(ch) 是编译报错的（类型为 <-chan T 时 invalid operation）。就算类型允许，也不该做——你无法判断是否还有发送者在途中。
更危险的是网上流传的“探测是否关闭”写法，例如：
select {
case v, ok := <-ch:
if !ok { /* 已关 */ }
default:
/* 空了？还是关了？分不清 */
}
这根本不可靠：它只能说明此刻非阻塞读失败，但无法区分“channel 空了”和“channel 关了”。正确做法只有两个：
- 用
for v := range ch—— 它内部自动处理关闭逻辑，你只需相信它 - 单次读用
v, ok := ，根据 <code>ok判断，而不是靠 select 试探
真正容易被忽略的点是：关闭 channel 和让 goroutine 退出，是两件事。关 channel 只影响读写行为；goroutine 是否退出，取决于它自己有没有检查信号（比如监听 ctx.Done() 或 done chan struct{}）并主动 return。
