Go语言中sync.WaitGroup是协调并发任务的利器但Add方法的调用位置暗藏玄机。许多开发者因忽略其执行时机的微妙差异导致协程阻塞或提前结束的隐蔽bug。本文将深入剖析这一陷阱的典型场景与规避策略助你写出更健壮的并发代码。Add方法调用时机误区在启动子协程后再调用Add是常见错误。由于Go调度器的不确定性主协程可能在子协程执行前就调用了Wait导致计数器为0而直接跳过等待。正确做法应在启动协程前完成Add操作确保计数器先于任务触发。例如循环内创建10个协程时需在循环外部统一Add(10)而非每次循环Add(1)后者可能因调度延迟引发竞态条件。嵌套任务中的计数器失控当WaitGroup用于多级任务时若在子函数内部调用Add容易因异常分支导致计数器未修正。比如某个子函数在错误处理时提前返回遗漏Done调用造成主流程永久阻塞。建议采用入口初始化模式在任务入口处显式Add总数量子函数仅负责Done通过defer确保执行。与defer联用的时序风险开发者常结合defer和Add来保证Done调用但若将Add置于defer中会导致逻辑倒置。例如在HTTP请求处理中若将Add延迟到Handler执行后可能因请求快速返回而使Wait提前结束。正确做法是将Add紧贴任务创建位置defer仅用于Done调用形成头尾呼应的明确生命周期。测试环境下的偶现陷阱单元测试中因模拟数据量小可能掩盖Add调用顺序问题。当测试代码使用真实并发量时原先隐藏的竞态条件会突然暴露。建议通过-race参数进行竞态检测并构造高压测试场景验证WaitGroup在临界状态下的行为是否符合预期。