任务编排依赖 channel 流向控制与生命周期协同，关闭方须明确、接收方须感知关闭；无缓冲 channel 适用于需 goroutine 对齐的同步点，如依赖初始化完成或前置任务就绪后发指令。
任务编排不是靠堆 goroutine 或套锁解决的，而是靠 channel 的流向控制和生命周期协同。核心判断就一条：谁决定任务结束，谁就负责关闭 channel；所有接收方必须能感知关闭，否则必然卡死或泄漏。
什么时候该用无缓冲 channel 做同步点
无缓冲 channel 的阻塞特性是天然的“握手协议”，适合强制两个 goroutine 在某个逻辑点上对齐。比如启动 worker 之前等所有依赖初始化完成，或者在主流程中等待一组前置任务全部就绪再发后续指令。
- 典型错误：用
make(chan struct{})当信号量但忘了 close，导致接收方永远阻塞 - 正确做法：发送方在确认前置条件满足后调用
close(done)，接收方用select { case 或 <code>for range done感知 - 注意：不能对同一个
done多次 close，panic 会直接崩掉整个 goroutine - 如果只是单次通知，
chan struct{}足够；需要传递状态时，改用chan error或带 payload 的结构体
如何避免 task channel 关闭时机错乱
任务 channel 的关闭必须发生在所有生产者退出之后、且确保没有新任务写入，否则 panic: send on closed channel；关太早又会让 worker 提前退出，漏掉已入队但未处理的任务。
- 最稳妥的方式是用
sync.WaitGroup管理所有生产者：每个生产者 defer wg.Done()，主 goroutine 在wg.Wait()后调用close(taskCh) - worker 必须用
for task := range taskCh模式读取，它会在 channel 关闭且缓冲区清空后自动退出 - 切忌在 worker 内部主动 close
taskCh——这是典型的职责错位，违反“谁创建谁关闭”原则 - 如果生产者本身是动态增删的（比如基于事件触发），就得换用
context.Context配合select判断退出，而不是依赖 close
结果收集为什么不能只靠 for range resultCh
for range resultCh 看似简洁，但前提是 resultCh 一定被关闭。而关闭时机取决于所有 worker 是否真正退出——这又依赖于 taskCh 是否被正确关闭、worker 是否处理完最后一项任务、有没有 panic 导致提前 return。
立即学习“go语言免费学习笔记（深入）”；
- 常见陷阱：worker 中有
recover()吞掉 panic，但没调用wg.Done()，导致主 goroutine 卡在wg.Wait()，resultCh 永远不关 - 推荐组合：用
sync.WaitGroup控制 worker 生命周期 + 单独 goroutine 在wg.Wait()后close(resultCh) - 更健壮的做法是把 resultCh 设为无缓冲，主 goroutine 每收一个结果就计数，达到预期数量后 break，绕过关闭依赖
- 如果结果顺序敏感，别用多个 worker 并发写同一
resultCh，改用带索引的结构体或分 channel 收集再 merge
真正难的不是写对某一行 close(ch)，而是理清数据流里谁在推、谁在拉、谁决定停——channel 只是管道，编排逻辑全在你的控制流设计里。
