在Go语言开发中，当我们通过go关键字启动成百上千个协程去执行异步任务时，主函数往往会在子协程尚未执行完毕时就已走到了尽头，从而导致整个程序直接退出。为了解决这种并发任务无法被有效等待的困境，标准库中的sync包提供了WaitGroup结构体。它就像是一个并发任务的计数器兼阻塞器，能够让发起方线程安心等待所有工作协程交付成果。
sync.WaitGroup的核心机制与基本用法
要理解sync.WaitGroup的工作原理，我们可以将其想象为一个带有阻塞功能的计数器。当你派发一个并发任务时，就给计数器加一；当任务结束，就给计数器减一；而负责等待的协程会一直卡在阻塞点，直到计数器彻底归零。这种机制避免了使用笨拙的time.Sleep硬编码等待，也无需引入复杂的通道通信即可实现简单的协同。
该结构体对外暴露了三个核心方法，分别是Add(int)、Done()和Wait()。其中Add方法用于增加或减少计数器的值，通常我们在启动协程前传入正数表示新增任务；Done方法本质上就是调用Add(-1)，用来在任务完成时注销自己；Wait方法则会阻塞调用它的协程，直到内部计数器变为零才会放行。这三个方法配合起来，就构成了Go并发编程中最基础的同步范式。
下面是一个最直接的使用示例，展示了如何启动五个协程并等待它们全部打印完毕。请注意，我们在循环启动协程之前就调用了wg.Add(1)，这是确保计数器准确的关键前置操作。代码中的循环条件使用了小于等于的比较，在pre代码块内已正确进行了HTML转义。
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
for i := 1; i <= 5; i++ {
wg.Add(1)
go func(id int) {
defer wg.Done()
fmt.Printf("协程 %d 执行完成\n", id)
}(i)
}
wg.Wait()
fmt.Println("主函数：所有协程均已退出")
}
编写健壮并发代码的避坑实践
虽然WaitGroup的API极其简单，但在实际工程里，很多初学者会因为调用时机不对而触发panic。最常见的错误是在go协程内部才调用Add方法。由于主协程的Wait可能先于子协程的Add执行，此时计数器还是零，Wait直接返回，导致主程序提前退出，或者更糟的是发生并发修改计数器的竞态条件，被Go的运行时不允许而崩溃。因此，永远在启动协程之前，在主协程的上下文中完成Add调用。
另一个极易被忽视的细节是异常安全。如果工作协程在执行过程中发生了panic或者提前return，而没有调用Done，那么计数器将永远无法归零，Wait所在的协程就会陷入永久死锁。解决这个问题的银弹是使用defer wg.Done()。通过将Done延迟绑定到函数退出阶段，无论协程是正常结束还是中途异常，计数器都能被正确释放。这种写法应当成为肌肉记忆。
当我们需要在循环中批量派发任务时，还要小心闭包变量捕获的陷阱。如果在匿名函数里直接引用循环变量而不作为参数传入，多个协程可能会共享同一个变量快照，导致逻辑错乱。下面的代码演示了正确的传参方式，以及结合defer保障稳定性的标准写法，这种结构在微服务批量调用下游接口时非常常见。
package main
import (
"fmt"
"sync"
"time"
)
func worker(taskID int, wg *sync.WaitGroup) {
defer wg.Done()
// 模拟业务处理耗时
time.Sleep(time.Millisecond * 100)
fmt.Printf("任务 %d 处理成功\n", taskID)
}
func main() {
var wg sync.WaitGroup
tasks := []int{101, 102, 103, 104}
for _, t := range tasks {
wg.Add(1)
go worker(t, &wg)
}
wg.Wait()
fmt.Println("批量任务全部落盘")
}
复杂场景下的WaitGroup进阶模式
在真实的后端系统中，我们往往不仅要等待协程结束，还要处理具体的输入输出。例如，在Windows服务器上并发读取多个分布在系统目录下的日志文件。这时候路径中的反斜杠必须原样保留，我们可以借助Go的 raw string 字面量来避免转义烦恼，同时利用WaitGroup统筹所有文件读取协程。这种场景在运维工具开发中十分普遍，能有效缩短批量采集耗时。
此外，WaitGroup还可以与带缓冲的channel组合使用，实现控制并发度的效果。如果直接无限制地启动协程，面对上万个任务时可能会耗尽系统资源。我们可以设置一个固定容量的channel作为信号量，在Add总数等于任务数的前提下，只有获取到信号量的协程才能运行，运行完通过Done通知WaitGroup。这样既享受了并发等待的便利，又保护了系统吞吐量。
以下示例展示了如何在Windows环境下并发读取多个系统路径日志，并正确保留路径反斜杠。代码中我们使用了反引号包裹路径字符串，确保像C:\Windows\System32这样的目录结构在编译和运行时都不会被错误解析，同时依靠WaitGroup确保所有文件句柄被安全关闭后才退出主流程。
package main
import (
"fmt"
"os"
"sync"
)
func main() {
var wg sync.WaitGroup
// 使用反引号原样保留Windows路径中的反斜杠
logPaths := []string{
`C:\Windows\System32\app1.log`,
`C:\Windows\System32\app2.log`,
`C:\Users\Admin\diagnose.log`,
}
for _, p := range logPaths {
wg.Add(1)
go func(path string) {
defer wg.Done()
data, err := os.ReadFile(path)
if err != nil {
fmt.Printf("路径 %s 读取异常: %v\n", path, err)
return
}
fmt.Printf("路径 %s 读取字节数: %d\n", path, len(data))
}(p)
}
wg.Wait()
fmt.Println("日志采集协程全部退出，释放资源")
}
性能考量与协程泄露防范
从底层实现来看，sync.WaitGroup内部是基于互斥锁和信号量机制实现的，它的Add和Done操作开销极小，在纳秒级别，因此完全不用担心频繁调用会带来性能瓶颈。真正需要开发者警惕的是协程泄露问题。如果因为逻辑漏洞导致某个分支忘记调用Done，或者Add的数量大于实际完成的Done数量，主协程就会在Wait处无限挂起，对应的子协程也会一直驻留内存。
为了防范这类隐患，在测试阶段可以借助Go自带的pprof工具包，定期采样goroutine数量。如果发现程序在空载时协程数只增不减，大概率是WaitGroup计数失衡。另外，在代码结构层面，建议将WaitGroup作为参数显式传递给工作函数，而不是设为全局变量，这样能明确权责边界，减少多人协作时的误用。
总的来说，sync.WaitGroup是Go语言给出的轻量级并发同步答案。它虽然不能替代context用于取消控制，也不能像channel那样传递数据，但在单纯的等待一批事情做完的需求面前，它是最直观、最高效的选择。把握好Add的调用时机、坚持defer Done、留意闭包与路径细节，你就能在各类业务场景中游刃有余地编排并发任务。
Golangsync.WaitGroup并发控制修改时间：2026-09-13 15:35:05