直接 close(channel) 会导致 panic 的原因是多个 goroutine 同时 close 已关闭的 channel，触发“close of closed channel”；正确做法是由唯一生产者关闭数据 channel，并用 done channel 或 context 控制消费者退出。
为什么直接 close(channel) 会导致 panic
生产者消费者模式里，如果生产者提前 close(ch)，而消费者还在用 range ch 循环读取，这本身是安全的；但若消费者用 单次接收，且没配合 <code>ok 判断，就会在 channel 关闭后继续读取，返回零值并引发逻辑错误——更危险的是，如果多个 goroutine 同时对已关闭 channel 调用 close()，会直接 panic：panic: close of closed channel。
所以退出控制不能依赖「谁先关 channel」，而要让生产者明确告知「数据发完了」，消费者感知到后自行退出。
- 永远不要让多个 goroutine 执行
close(ch) -
range ch是安全的，它内部自动检测 closed 状态并退出循环 - 单次接收必须写成
v, ok := ，靠 <code>ok == false判断是否结束
用 done channel + sync.WaitGroup 协调退出
最稳妥的做法是：用一个 done channel 通知所有 goroutine 该停了，再用 sync.WaitGroup 等待它们真正退出。这样生产者可以优雅终止（比如收到信号、处理完一批任务），消费者也能在本轮消费完后退出，不丢数据也不阻塞。
示例关键结构：
done := make(chan struct{})
var wg sync.WaitGroup
<p>// 启动消费者
for i := 0; i < 3; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for {
select {
case v, ok := <-jobs:
if !ok { return } // jobs 关闭，退出
process(v)
case <-done:
return // 外部要求退出
}
}
}()
}</p><p>// 生产者：发完数据后 close(jobs)，再 close(done)
go func() {
for _, job := range allJobs {
select {
case jobs <- job:
case <-done:
return
}
}
close(jobs) // 仅此处 close，且只一次
close(done) // 通知消费者可以彻底收工了
}()</p><p>wg.Wait()
用 context.Context 替代 done channel 更灵活
当需要支持超时、取消链路或与 HTTP/gRPC 等生态集成时，context.Context 比裸 done chan struct{} 更合适。它自带取消传播和 deadline 支持，且 ctx.Done() 返回的 channel 可直接用于 select。
- 用
context.WithCancel创建可取消上下文 - 生产者在完成或出错时调用
cancel() - 消费者监听
，而不是自己维护 <code>donechannel - 注意：消费者仍需正确处理
jobs关闭（如range jobs或v, ok := ）
常见误用：ctx 仅用于控制生命周期，不能替代数据 channel 的关闭逻辑——jobs 还是要由生产者显式 close()，否则消费者可能永远卡在 上。
消费者用 range 还是 select？取决于是否要响应外部中断
如果消费者只需要等数据发完就退出，用 for v := range jobs 最简洁，它隐含了对 closed channel 的处理；但如果还要响应超时、强制取消或多个输入源（比如同时从 jobs 和 control channel 读），就必须用 select。
-
range jobs：适合纯数据流、无中断需求的场景，代码少、不易错 -
select+：必须配 <code>ok判断，否则关 channel 后继续读会拿到零值 -
select+ctx.Done()：能及时响应取消，但要注意：即使ctx取消了，也应确保已接收的数据被处理完（比如把v放进本地队列再退出）
最容易被忽略的一点：无论用哪种方式，只要生产者 close 了 jobs，所有正在 的 goroutine 都会立刻解除阻塞——所以「退出」不是瞬间发生的，而是按当前正在执行的语句自然流转结束。别指望一 cancel 就立马全部停住。
