用channel做任务流转更可控，因其具备缓冲、阻塞语义和显式数据契约，可限流、等待完成、统一错误处理，并支持日志、重试、超时等扩展逻辑。
为什么用 channel 做任务流转比直接起 goroutine 更可控
因为 channel 天然带缓冲、阻塞语义和显式数据契约，能避免 goroutine 泛滥、任务丢失或竞态。直接 go f(task) 无法限流、无法等待完成、无法统一错误处理；而用 chan Task 可以把“发任务”和“执行任务”解耦，中间还能插日志、重试、超时等逻辑。
常见错误是把 channel 当成“队列”盲目塞任务，却不设缓冲或不检查接收方是否存活，导致 sender 永久阻塞或 panic。
- 始终为
chan Task设置合理缓冲（如make(chan Task, 100)），除非你明确需要同步握手 - 启动 worker 时用
for range消费，且在defer close()或外部控制关闭前不要退出循环 - 发送任务前先用
select+default判断 channel 是否已满或已关闭，避免死锁
如何安全关闭任务 channel 并等待所有 worker 结束
直接 close(ch) 后，worker 的 for range ch 会自然退出，但主 goroutine 需要确认所有 worker 真的结束了——不能只靠 close()，必须配合 sync.WaitGroup 或 context.WithCancel。
典型陷阱是：close(ch) 后立刻 wg.Wait()，但某个 worker 还在处理上一个任务，没来得及读完 channel 就被 wg 计数抵消了，造成漏处理。
立即学习“go语言免费学习笔记（深入）”；
- worker 内部用
for task := range ch，确保读完所有已入队任务 - 主 goroutine 调用
close(ch)前，先停止投递新任务（比如 break 外层循环） -
wg.Add(1)在启动每个 worker 之前调用，wg.Done()放在 worker 函数末尾（即for循环结束后） - 如果 worker 内有阻塞操作（如 HTTP 请求），需额外加
ctx.Done()检查，防止卡死不退出
如何给任务 channel 加超时、重试和错误反馈
纯 chan Task 不带元信息，没法标记失败、重试次数或截止时间。实际流转中，任务本身应封装上下文，而不是依赖 channel 外部状态。
例如，把 Task 定义为结构体，包含 ID、Data、RetryCount、Deadline time.Time 和 Done chan error 字段，worker 执行完往 Done 写结果，主 goroutine 用 select 等待。
- 重试逻辑放在 worker 内：若
err != nil && t.RetryCount ，则构造新 <code>Task并重新 send 到原 channel - 超时判断用
if time.Now().After(t.Deadline)，避免依赖外部 timer channel 增加复杂度 - 错误反馈通道
Done chan error必须带缓冲（至少 1），否则 worker 写入时可能阻塞 - 不要用全局 map 存
taskID → resultChan，容易泄漏；每个 task 自带Done是最干净的方式
goroutine 泄漏的三个高发场景与修复方式
channel 任务流中最隐蔽的问题不是 panic，而是 goroutine 持续增长却无感知——比如 worker 因未处理 ctx.Done() 卡在 IO 上，或 sender 在 channel 关闭后仍尝试发送。
用 runtime.NumGoroutine() 打印只是辅助，关键是要从设计上堵住泄漏路径。
- worker 中所有阻塞调用（
http.Do、time.Sleep、ch ）都套 <code>select { case 或用带 ctx 的变体（如 <code>http.NewRequestWithContext） - sender 使用
select发送：case ch 正常；<code>case 放弃；<code>default:缓冲满时跳过或记录告警，绝不裸写ch - 避免在闭包中捕获外部 channel 变量并反复启动 goroutine，尤其注意 for 循环里
go func(i int) { ch 这类写法——i 可能被多个 goroutine 共享
真正难调试的是那些“看起来跑完了”的 worker，其实还在等一个永远不会来的 response。channel 本身不保活，保活靠的是你写的每一条 select 分支和每一个 ctx 检查点。
