sync.waitgroup 忘记 add 就调 done 会必现 panic: sync: negative waitgroup counter；必须在 goroutine 启动前调用 wg.add(1)，不可在内部或延迟调用。
Go test 中 sync.WaitGroup 忘记 Add 导致 panic
测试里用 sync.WaitGroup 等待 goroutine 完成，但没调 WaitGroup.Add 就直接 Done，会触发 panic: sync: negative WaitGroup counter。这不是偶发，是必现——因为 Done 本质是原子减一，初始值为 0，减一就崩。
- 必须在
go语句前调用wg.Add(1)，不能放在 goroutine 内部（除非你确定它一定会执行） - 如果启动 N 个 goroutine，
Add要在循环外一次性加 N，或在循环内每次加 1；别用wg.Add(len(jobs))后再遍历启动，否则存在竞态：goroutine 可能先执行Done，而Add还没完成 - 测试中更推荐显式计数：比如
for i := 0; i
用 testing.T.Parallel() 时误共享 struct 字段
多个并行测试子例程（subtest）共用同一个 struct 实例的字段，比如 type fixture struct { mu sync.RWMutex; data map[string]int }，不加锁直接读写 data，会触发 data race 报告，甚至测试结果错乱。
-
t.Parallel()不自动隔离变量作用域，只控制执行调度；所有闭包捕获的外部变量仍是共享的 - 每个并行 subtest 应该拥有独立的 fixture 实例，或确保对共享状态的操作被
mu.Lock()/RWMutex.RLock()保护 - 常见错误：在
for _, tc := range tests循环里启动func(t *testing.T) { t.Parallel(); ... use(tc) ... }，但tc是循环变量地址，所有 goroutine 实际读的是最后一个tc的值——必须用局部副本：tc := tc
time.Sleep 在并发测试里不是同步手段
写测试时用 time.Sleep(10 * time.Millisecond) 等待 goroutine 执行完，看似“跑过了”，实则不可靠：CPU 负载高时 sleep 不够，CI 环境可能直接跳过断言；低负载时又拖慢测试速度。
-
time.Sleep是时间等待，不是事件等待；它无法保证某段逻辑已执行、某次 channel 发送已完成、某个 mutex 已释放 - 正确替代方案优先级：channel 接收 >
sync.WaitGroup>sync/atomic标志位 > 最后才考虑带超时的time.AfterFunc或select+time.After - 示例：不要
go doWork(); time.Sleep(5ms); assert.Equal(t, expected, globalVar)；改用c := make(chan struct{}); go func() { doWork(); close(c) }();
测试 sync.Once 行为时忽略多 goroutine 初始化竞争
验证 sync.Once.Do 是否真的只执行一次，仅用单 goroutine 调用 once.Do(f) 并检查返回值，根本测不出并发安全特性。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式启动多个 goroutine 同时调用
once.Do，再通过共享计数器（如atomic.Int64）确认f仅被执行一次 - 注意：
Do返回后，不表示f已执行完毕——只是提交了执行请求；若需验证副作用（如写文件、改全局状态），得配合 channel 或 mutex 等同步原语确认f真的退出 - 容易漏掉的点：测试中用
var once sync.Once; once.Do(func(){ ... })，但没检查f内部是否 panic；一旦 panic，Once会标记为已执行，后续调用直接返回，但行为不符合预期
并发测试里最麻烦的从来不是写多少 goroutine，而是怎么让它们“同时开始”又“可验证地结束”。sync.WaitGroup 和 channel 是基础，但初始化时机、变量捕获、panic 传播这些细节，稍不注意就让测试变成“看着绿，其实没测到”。
