WaitGroup 可安全重用，前提是 wg.Wait() 已返回且计数器确认为0；此时可立即 wg.Add(n) 启动新任务，但禁止在 Wait 阻塞时并发 Add 或跨作用域值传递导致状态分裂。
WaitGroup 重用本身安全，但“状态不一致”几乎总是源于误用而非重用本身。 它不是一次性对象，计数器归零后可再次 Add()；真正危险的是在 Wait() 尚未返回时并发调用 Add()，或跨作用域传值导致副本失效。
WaitGroup 什么时候能安全重用？
只有当 wg.Wait() 已返回、且计数器确认为 0 时，才能继续 wg.Add(n) 启动新一批任务。这不是“复位”，而是自然回到零值状态后的合法续用。
- ✅ 安全：启动 3 个 goroutine →
wg.Wait()返回 → 立即wg.Add(5)启动下一批 - ❌ 危险：
wg.Wait()还在阻塞，另一个 goroutine 调wg.Add(1)→ panic “WaitGroup misuse” - ⚠️ 高危：HTTP handler 中把
wg作为 struct 字段存起来反复用 —— 实际上每次请求都该用新声明的var wg sync.WaitGroup
为什么传值会导致“状态不一致”？
sync.WaitGroup 内部含 noCopy 字段（如 state1 [3]uint32），值拷贝会分裂原子状态。副本上的 Done() 对原实例计数器毫无影响，表现为 Wait() 永久阻塞或提前返回。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- ❌ 错误写法：
func worker(wg sync.WaitGroup)、subWg := wg、handlers = append(handlers, struct{ wg sync.WaitGroup }{wg}) - ✅ 正确写法：始终用指针，
func worker(url string, wg *sync.WaitGroup)，调用时传&wg - ⚠️ 注意：Go 1.21+ 的
go vet会对隐式拷贝（如append含 WaitGroup 的切片）报错
循环中 Add/Done 配对最容易漏在哪？
不是语法错，而是逻辑路径覆盖不全 —— 尤其在有 error early return 或 panic 的 goroutine 函数里，defer wg.Done() 必须出现在函数最开头，否则某些退出路径会跳过。
立即学习“go语言免费学习笔记（深入）”；
- ❌ 危险写法：
if err != nil { return err }出现在defer wg.Done()之前 - ✅ 推荐写法：
func task(id int, wg *sync.WaitGroup) { defer wg.Done(); if err := doWork(); err != nil { return } - ⚠️ 闭包陷阱：用
for i := range items启动 goroutine 时，所有闭包共享同一个i变量 → 某些Done()被跳过 → 计数卡住。解法是显式传参：go task(items[i], &wg)
真正难的不是记住“能重用”，而是在嵌套了 context、channel、错误处理的业务函数里，还能一眼看清每个 Add() 是否有对应且必执行的 Done()。别靠记忆，拆小函数、加注释、开 go vet，比硬扛靠谱。
