Golang多任务协作实现技巧

亲爱的编程学习爱好者，如果你点开了这篇文章，说明你对《Golang多任务协同实现方法》很感兴趣。本篇文章就来给大家详细解析一下，主要介绍一下，希望所有认真读完的童鞋们，都有实质性的提高。

WaitGroup 必须在启动 goroutine 前调用 Add，否则可能阻塞或 panic；正确做法是先 wg.Add(n)，再启 n 个 goroutine，每个结尾调 wg.Done()；注意闭包陷阱，避免循环变量引用错误。

WaitGroup 必须在启动 goroutine 前完成 Add

常见错误是先 go func() { ... }() 再调用 wg.Add(1)，导致 wg.Wait() 永远阻塞或 panic：「panic: sync: negative WaitGroup counter」。这是因为 Add 和 Done 不是原子配对操作，必须确保计数器在 goroutine 开始执行前已初始化。

正确做法是：先 wg.Add(n)，再启动 n 个 goroutine；每个 goroutine 结束前调用 wg.Done()（或用 defer wg.Done()）。

• wg.Add() 必须在所有 go 语句之前，或至少在对应 goroutine 执行 wg.Done() 之前
• 不要在循环里反复 wg.Add(1) 后立刻 go —— 要么提前算好总数一次性 Add，要么确保每次 Add 紧邻其对应的 go
• 如果任务数量动态不确定，先遍历一次收集任务，再 Add(len(tasks))，最后统一启动

goroutine 中访问外部变量要小心闭包陷阱

在 for 循环中直接启动 goroutine 并引用循环变量（如 for i := 0; i ），最终可能全部打印 3。这是因为所有 goroutine 共享同一个变量 i 的地址，等它们真正执行时，循环早已结束，i 值为终值。

修复方式是把变量作为参数传入 goroutine 函数，让每个实例拥有独立副本：

for i := 0; i 
或者用局部变量显式捕获：
for i := 0; i 
WaitGroup 不能被复制，必须传指针
sync.WaitGroup 是包含 mutex 和计数器的结构体，禁止值传递。如果函数参数写成 func worker(wg sync.WaitGroup) 或在 goroutine 中传入 wg 值，会导致：fatal error: sync: WaitGroup is reused before previous Wait has returned。

• 所有对 WaitGroup 的操作（Add、Done、Wait）都必须作用于同一地址上的实例
• 跨函数调用时，参数类型必须是 *sync.WaitGroup
• 启动 goroutine 时，若需在其中调用 Done，也必须传 &wg，而不是 wg

WaitGroup 不处理 panic，需配合 recover 或日志兜底

WaitGroup 只负责计数和阻塞，不捕获 goroutine 内部 panic。一旦某个 goroutine panic，程序可能崩溃，而 wg.Wait() 还没返回，主流程无法得知哪些任务失败。

实际工程中建议：

• 在每个 goroutine 入口加 defer func(){ if r := recover(); r != nil { log.Printf("goroutine panic: %v", r) } }()
• 用带错误通道的模式汇总结果，例如 errCh := make(chan error, n)，每个 goroutine 执行完发 errCh <- err，主协程从通道收错误并判断是否全成功
• 避免在 WaitGroup 场景中依赖 panic 做流程控制 —— 它不是错误传播机制

WaitGroup 的核心就三件事：预设数量、各自归零、统一等待。最容易出问题的地方不在语法，而在「谁在什么时候改了计数器」—— 多线程下这点时序稍一错乱，表现就是卡死或 panic，而且难以复现。写的时候多看两眼 Add 和 go 的顺序，比事后 debug 强得多。

理论要掌握，实操不能落！以上关于《Golang多任务协作实现技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！