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 <p>这种写法规避了所有关闭时机问题：不关 channel、不依赖 <code>range</code> 语义、不会 panic、逻辑一目了然。适用于任务总数固定、发送者与接收者职责清晰的场景。</p><h3>必须用 for range 时，谁关、何时关、怎么关</h3><p>若业务逻辑天然适合 <code>for range</code>（比如流式处理不确定长度的数据），则关闭动作必须满足三个硬约束：</p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill5461" title="Cross-Channel Notify"><img src="https://img.php.cn/upload/skill/000/000/081/179050330744021.jpg" alt="Cross-Channel Notify" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill5461" title="Cross-Channel Notify" class="overflowclass">Cross-Channel Notify</a> <p class="overflowclass">一次同时通过邮件(Himalaya)和iMessage(BlueBubbles)发送相同通知。用于用户想要通过多渠道广播或通知某人时使用。</p> </div> <a rel="nofollow" href="/xiazai/skill5461" title="Cross-Channel Notify" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
-
谁关：只能由「最后一个可能往
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) 是编译报错的（类型为 时 invalid operation）。就算类型允许，也不该做——你无法判断是否还有发送者在途中。
更危险的是网上流传的“探测是否关闭”写法，例如：
select {
case v, ok := <p>这根本不可靠：它只能说明此刻非阻塞读失败，但无法区分“channel 空了”和“channel 关了”。正确做法只有两个：</p>
- 用
for v := range ch—— 它内部自动处理关闭逻辑，你只需相信它 - 单次读用
v, ok := ，根据 <code>ok判断，而不是靠 select 试探
真正容易被忽略的点是：关闭 channel 和让 goroutine 退出，是两件事。关 channel 只影响读写行为；goroutine 是否退出，取决于它自己有没有检查信号（比如监听 ctx.Done() 或 done chan struct{}）并主动 return。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
