本文详解go中sync.waitgroup未按预期阻塞的典型问题，核心在于for循环中goroutine捕获变量的闭包陷阱，提供两种安全传参方案并附可运行示例。
本文详解go中sync.waitgroup未按预期阻塞的典型问题，核心在于for循环中goroutine捕获变量的闭包陷阱，提供两种安全传参方案并附可运行示例。
在使用 sync.WaitGroup 控制并发 goroutine 执行流程时，一个高频且隐蔽的错误是：wg.Wait() 看似被调用，但程序却立即返回，goroutine 未真正执行完毕，甚至输出全为 0 或 panic。这并非 WaitGroup 本身失效，而是典型的 变量捕获（closure capture）陷阱——尤其发生在 for range 循环中启动 goroutine 的场景。
? 问题根源：共享变量 vs 独立副本
原始代码的问题在于：
for _, myurl := range listOfUrls {
go func() {
body := getUrlBody(myurl) // ❌ 所有 goroutine 共享同一个 myurl 变量！
fmt.Println(len(body))
wg.Done()
}()
}Go 中 for range 的迭代变量 myurl 在整个循环中是复用的同一内存地址。当 goroutine 实际执行时（可能在循环结束后），myurl 已被更新为最后一次迭代的值，甚至超出范围（如空字符串或零值）。因此所有 goroutine 都在处理“过期”的 myurl，导致 getUrlBody("") 返回空内容，len(body) 为 0。
✅ 关键原则：每个 goroutine 必须持有其所需参数的独立副本，而非对循环变量的引用。
立即学习“go语言免费学习笔记（深入）”；
✅ 正确解法一：将变量作为参数传入匿名函数（推荐）
通过显式将当前迭代值作为参数传递给闭包，确保每个 goroutine 拥有专属副本：
func printSize(listOfUrls []string) {
var wg sync.WaitGroup
wg.Add(len(listOfUrls)) // 注意：原文 typo "listOfUrl" 已修正
for _, myurl := range listOfUrls {
go func(url string) { // ✅ 参数 url 是独立副本
body := getUrlBody(url)
fmt.Printf("URL: %s → Body length: %d\n", url, len(body))
wg.Done()
}(myurl) // ✅ 立即传入当前 myurl 值
}
wg.Wait() // ✅ 安全阻塞，直到所有 goroutine 调用 Done()
}✅ 正确解法二：在循环内重新声明变量（等效但稍隐晦）
利用 Go 的短变量声明 := 在每次迭代中创建新变量，覆盖外层 myurl 的引用：
func printSize(listOfUrls []string) {
var wg sync.WaitGroup
wg.Add(len(listOfUrls))
for _, myurl := range listOfUrls {
myurl := myurl // ✅ 创建同名新变量，绑定当前迭代值
go func() {
body := getUrlBody(myurl) // ✅ 此时闭包捕获的是新变量 myurl
fmt.Printf("URL: %s → Body length: %d\n", myurl, len(body))
wg.Done()
}()
}
wg.Wait()
}⚠️ 注意事项与最佳实践
- wg.Add() 必须在 goroutine 启动前调用：否则存在竞态（Add 和 Done 并发修改计数器）。
- 避免 wg.Add(0) 或负数：会导致 panic；确保 Add 参数与实际启动的 goroutine 数量严格一致。
-
wg.Done() 必须被调用且仅调用一次：建议用 defer wg.Done() 防止遗漏（尤其在含 error 分支的函数中）：
go func(url string) { defer wg.Done() // 更健壮 body := getUrlBody(url) fmt.Println(len(body)) }(myurl) - WaitGroup 不可复制：应作为局部变量或指针传递，切勿值拷贝。
- 调试技巧：在 goroutine 内打印 &myurl 地址，可直观验证是否所有 goroutine 共享同一地址。
? 补充：完整可运行示例（含模拟 getUrlBody）
package main
import (
"fmt"
"sync"
"time"
)
func getUrlBody(url string) string {
// 模拟网络延迟（真实场景中应加超时控制）
time.Sleep(time.Second * 1)
return url + "_fake_body_content"
}
func printSize(listOfUrls []string) {
var wg sync.WaitGroup
wg.Add(len(listOfUrls))
for _, myurl := range listOfUrls {
myurl := myurl
go func() {
defer wg.Done()
body := getUrlBody(myurl)
fmt.Printf("[✅] %s → %d bytes\n", myurl, len(body))
}()
}
fmt.Println("[⏳] Waiting for all requests...")
wg.Wait()
fmt.Println("[✔️] All done!")
}
func main() {
urls := []string{"https://example.com", "https://golang.org", "https://github.com"}
printSize(urls)
}运行此代码将看到三条带延迟的日志依次输出，最后打印 All done! —— 这正是 WaitGroup 正确生效的表现。
掌握这一闭包陷阱的本质，不仅能解决 WaitGroup 不等待的问题，更是写出健壮并发 Go 代码的关键基石。
