不能仅靠 close + range 确保数据收全、顺序可靠、goroutine 干净退出；关闭时机须由唯一生产者控制，多生产者并发 close 会 panic，提前 close 会导致漏收。
高并发任务流中用 channel 做同步，**不能只靠 close + range 就认为数据一定收全、顺序一定可靠、goroutine 一定退出干净**。核心问题在于：channel 关闭时机、接收方是否已就绪、是否存在漏收或重复收，这些在多生产者/多消费者场景下极易出错。
关闭 channel 的时机必须由唯一确定的生产者控制
多个 goroutine 同时调用 close(ch) 会 panic：panic: close of closed channel。更隐蔽的问题是：若某个生产者提前 close，其他生产者还在发，ch 会直接 panic（向已关闭 channel 发送）。
- 永远不要让多个生产者各自判断“我发完了就关”
- 用
sync.WaitGroup汇总所有生产者完成信号，再由主 goroutine 或专用协调 goroutine 统一 close - 或者改用
context.Context配合select，用ctx.Done()通知停止发送，而非依赖 close
range ch 不等于“安全等所有数据”
for v := range ch 确实会在 channel 关闭且缓冲区清空后自动退出，但它**不保证你看到的是“最终一致”的快照**——尤其当生产者未按预期关闭、或存在未被 waitgroup 覆盖的 goroutine 时，range 可能提前结束，漏掉后续抵达的数据。
- 如果生产者逻辑含异步分支（如嵌套 goroutine、定时重试），
range很可能收不到那些分支发出的数据 - 缓冲 channel（如
make(chan int, 100)）中残留数据不会触发 panic，但若关闭过早，range 会退出而缓冲区里还有未读值 - 替代方案：用
len(ch)+ 循环接收，或显式计数（如通过sync.WaitGroup记录应接收总数）
多消费者竞争同一 channel 时，数据分发不可控
多个 goroutine 同时对同一个 unbuffered 或 buffered channel 执行 ，Go 运行时会随机唤醒一个接收者。这意味着：你无法保证某条任务被哪个 worker 处理，也无法保证处理顺序与发送顺序一致（即使发送是串行的）。
- 若业务要求“严格 FIFO”或“指定 worker 处理”，不要把所有任务塞进一个 channel，改用 per-worker channel 或加路由逻辑
- 若需负载均衡，用 buffered channel + 合理容量（如
make(chan Task, runtime.NumCPU())），避免过度堆积或频繁阻塞 - 注意：worker 死锁风险——若所有 worker 都在等新任务，但生产者已退出且 channel 未 close，
range或会永久阻塞
超时与取消必须显式集成，不能依赖 channel 自身
channel 本身不提供超时能力。一旦 阻塞，它就一直等下去，除非有 sender、channel 关闭，或你主动介入。
- 所有关键接收操作必须包裹在
select中，搭配time.After或ctx.Done() - 例如：
select { case v := - 忽略超时会导致 goroutine 泄露——尤其在 worker 池中，一个卡死的 worker 会持续占用资源，且无法被外部感知
真正难的不是写通 channel，而是厘清谁负责关、谁负责收、谁负责兜底超时、谁来验证数据完整性。这些边界一旦模糊，高并发下的行为就会退化成概率性正确。
