WaitGroup在HTTP框架中易出错，因handler并发调用时若wg作用域管理不当，会导致值传递计数器分裂、复用未重置引发负值panic、Add/Done配对缺失或闭包变量捕获错误，必须每请求独立声明、传指针、Add在go前、defer Done于函数首行。
WaitGroup 不是框架组件，它是 Go 标准库 sync 包里的一个轻量同步原语，任何 Go 程序（包括用 Gin、Echo、Gin 等框架写的后端）都能直接用，但必须手动配对 Add/Done，错一次就 panic 或死锁。
为什么在框架里用 WaitGroup 容易出错
HTTP 框架的 handler 是并发调用的，每个请求都可能启动多个 goroutine。如果在 handler 内部声明 var wg sync.WaitGroup 却没注意作用域和生命周期，常见问题包括：
- 把
wg作为局部变量传给子函数但用了值传递（func f(wg sync.WaitGroup)），导致内部Add和外部Wait操作的是两个拷贝，计数器分裂 →Wait()永远不返回 - 在中间件或异步日志中误复用同一个
wg实例处理多轮请求（比如长连接场景下反复Add但没重置）→ 计数器负值 panic - handler 中启动 goroutine 后忘记加
wg.Add(1)，或提前 return 时漏掉defer wg.Done()→Wait()卡住，整个请求超时 - 闭包捕获循环变量（如
for i := range tasks { go func() { ... }() }），导致多个 goroutine 共享同一个i，某些Done()被跳过
WaitGroup 在 HTTP handler 中的正确写法
核心原则：每个请求生命周期内独立使用一个 sync.WaitGroup，且所有操作必须由该 handler 的主 goroutine 串行发起。
-
wg.Add(1)必须在go语句之前，一一对应 - goroutine 内必须用
defer wg.Done()，不能裸调wg.Done() - 需要传参进 goroutine 时，显式传值（
go f(x)），不要依赖外部循环变量 - 若需跨函数协作（如拆分任务逻辑到子函数），参数传
*sync.WaitGroup，不是值
示例（Gin handler）：
立即学习“go语言免费学习笔记（深入）”；
func handleTasks(c *gin.Context) {
var wg sync.WaitGroup
urls := []string{"https://a.com", "https://b.com"}
for _, url := range urls {
wg.Add(1)
go func(u string) {
defer wg.Done()
// ... http.Get(u)
}(url) // 显式传参，避免闭包陷阱
}
wg.Wait()
c.JSON(200, gin.H{"status": "done"})
}
WaitGroup 和 context.WithTimeout 组合使用的关键点
真实业务中不能只等，还要防卡死。WaitGroup 本身不支持超时，必须靠 context 配合：
- 不要在
Wait()上套select+time.After——Wait()是阻塞调用，无法中断 - 正确做法：用
context.WithTimeout控制整个任务组的生命周期，在每个 goroutine 内检查ctx.Err()并提前退出，同时仍调用wg.Done() - 主 goroutine 在
select中等待wg完成或 context 超时，两者都需处理
错误示范：select { case —— 这样超时后 <code>Wait() 还在阻塞
正确思路：让每个 goroutine 自己响应 cancel，并确保 Done() 总被执行。
别把 WaitGroup 当 channel 用
WaitGroup 只回答一个问题：“所有任务是否已标记完成？”，它不传数据、不保序、不通知结果。常见误用：
- 想用它收集返回值 → 应该配合
channel或切片 +sync.Mutex - 以为
Wait()返回后就能安全读共享变量 → 若无额外同步（如 mutex 或 atomic），仍是竞态 - 在 goroutine 内反复
wg.Add(1)做循环任务 → 不可重用，应每次新声明var wg sync.WaitGroup
最易被忽略的细节：WaitGroup 的 zero value 是可用的，但一旦计数归零，它就进入终态；后续若有人偷偷往里 Add 再 Wait，行为未定义 —— 不是 panic，而是可能永远等不到唤醒，尤其在高并发 handler 中极难复现。
