sync.WaitGroup 用于精确控制已知数量的 goroutine 生命周期：主线程调用 wg.Add(n) 声明任务数，各 goroutine 结束前调用 wg.Done()，主协程 wg.Wait() 阻塞等待；Add 必须在启动 goroutine 前完成，避免竞态。
用 sync.WaitGroup 控制任务生命周期，别只靠 go 启动就完事
并发启动 goroutine 很容易，但等所有任务结束才是关键。漏掉等待会导致主函数提前退出，任务被强制终止。
-
sync.WaitGroup是最轻量、最直接的同步方式：调用wg.Add(n)声明待处理数量，每个 goroutine 结束前调用wg.Done()，主协程用wg.Wait()阻塞直到全部完成 - 常见错误是把
wg.Add()放在循环内但没加锁，或在 goroutine 里调用wg.Add(1)导致竞态 —— 必须在启动 goroutine 之前，在主线程中一次性Add - 如果任务数动态变化（比如从 channel 持续读取），改用
context.WithCancel+for range更稳妥，WaitGroup适合已知总量的批处理场景
用带缓冲的 channel 做任务队列，避免无限制创建 goroutine
直接对每个任务起一个 goroutine 看似简单，但遇到上万任务时会迅速耗尽内存和调度器资源，甚至触发 OOM 或系统级限流。
- 典型做法是启动固定数量的工作协程（比如
runtime.NumCPU()或按压测结果设定），共用一个chan Task接收任务 - channel 必须带缓冲：
make(chan Task, 1000)，否则发送端可能阻塞，失去“提交即返回”的语义 - 注意关闭 channel 的时机：由生产者关闭，消费者用
for task := range ch安全退出；别在多个 goroutine 里重复关，会 panic
用 context.Context 实现超时与取消，别让失败任务卡死整个处理器
网络请求、数据库查询、外部 API 调用都可能长时间无响应，不设超时会让整个任务队列停滞，甚至拖垮下游服务。
- 每个任务应接收一个
ctx context.Context参数，在关键阻塞点（如http.Client.Do、db.QueryContext）传入 - 主流程可统一设置超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，并在 defer 中调用cancel() - 若需支持手动中断（如管理接口触发停止），用
context.WithCancel，把cancel函数暴露给控制逻辑即可
错误要聚合上报，别在 goroutine 里默默吞掉 err
goroutine 内部 panic 不会被外层捕获，普通 error 若只打印不收集，上线后根本不知道哪类任务失败率高、是否批量出错。
立即学习“go语言免费学习笔记（深入）”；
- 定义统一错误通道：
errCh := make(chan error, len(tasks))，每个任务执行完把err发进去（nil也发，方便计数） - 主协程用
for i := 0; i 收集结果 - 更健壮的做法是用结构体封装结果：
type Result { TaskID string; Err error; Output interface{} }，便于后续做熔断、重试或审计
真正难的不是并发本身，而是当任务量、失败率、依赖延迟同时波动时，如何让处理器不雪崩、可观测、可干预 —— 这些细节往往在压测阶段才暴露，别等线上报警才补 context 和 channel 缓冲大小。
