Golang单元测试中如何检测函数并发读写冲突？竞态检测器使用【避坑】

go test -race 必须实际运行并发代码才生效，未报竞态不等于无问题；需确保测试等待所有goroutine结束、避免值传递含锁结构体、正确使用锁覆盖全部访问路径，并在CI中控制并发数与超时。

go test -race 必须跑起来才算生效

没报竞态 ≠ 没问题，根本原因是 go test -race 只捕获运行时真实发生的读写交错，不是静态扫描。测试代码里启动了 goroutine，但没等它执行完就退出，或者只串行调用一次被测函数，-race 就完全没机会看到冲突。

• 确保测试函数以 _test.go 结尾，且含 func TestXXX(t *testing.T)
• 用 sync.WaitGroup 或 chan struct{} 等待所有 goroutine 结束，别用 time.Sleep() —— 时间短了漏触发，长了拖慢测试
• 并发数别设 2 或 5，至少 const N = 1000，提高调度器交错概率
• 如果被测逻辑依赖 HTTP、定时器等，测试中必须 mock 或缩短超时，否则 -race 可能因超时提前终止而跳过关键路径

struct 字段加了 mutex 还报 race？先查值传递

常见真 Bug 是：结构体含 sync.Mutex，但函数参数或 map value 用了值传递，导致每次传参都复制出一个新 mutex，原锁失效。race detector 会照常报警，因为实际没锁住共享字段。

• 所有含 sync.Mutex 的 struct，函数参数、返回值、map value、channel 元素一律用指针 *MyStruct
• 检查是否在 defer mu.Unlock() 前漏了 mu.Lock()，尤其 if 分支里加锁、else 里没加的情况
• 确认 Lock()/Unlock() 覆盖全部读写路径 —— 比如某个方法只读字段却没加 RLock()，另一个方法写却用 Lock()，也算未同步
• 避免对 struct 做深拷贝（如 json.Unmarshal 到新实例），拷贝后锁和数据就分离了

map 并发读写别只盯着 panic，要靠 -race 定位真实写入点

fatal error: concurrent map writes 只告诉你炸了，但不知道哪两处代码在争。而 go test -race 会打出具体地址和两个 goroutine 的完整调用栈，这才是修复依据。

• panic 堆栈通常停在 runtime.mapassign，无意义；-race 报告里的 Write at 0x... by goroutine X 和 Previous write at 0x... by goroutine Y 才是真实冲突行
• 别一上来就换 sync.Map —— 它适合读多写少、不遍历、键生命周期长的场景；写频繁或需 len()/range 统计时，sync.RWMutex 包普通 map 更稳
• 如果用指针传 map（如 func update(m *map[string]int)），注意别在 goroutine 内执行 *m = make(...) —— 底层地址变了，-race 就无法关联历史访问

CI 里跑 -race 失败或超时？不是配置问题，是测试本身没控好 goroutine

CI 中 go test -race 偶发失败或超时，大概率不是工具问题，而是测试里 goroutine 泄漏或没设超时保护。

立即学习“go语言免费学习笔记（深入）”；

• 每个并发测试必须配 ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，并在 goroutine 启动时传入 ctx，防止卡死
• 用 sync.WaitGroup 时，wg.Add() 必须在 go 前调用，且数量与启动 goroutine 数严格一致
• CI 环境资源受限，-race 本身变慢 2–5 倍、内存翻倍，所以测试并发数不宜盲目拉高，建议从 100 开始压测，再逐步调
• 第三方库内部的竞态也会被 -race 报出，堆栈可能停在你调用它的那一行 —— 别直接改自己代码，先确认是不是复用了不该共享的全局实例（如 http.DefaultServeMux）

真正容易被忽略的是：竞态不是“有没有锁”，而是“锁是否覆盖了所有访问路径 + 是否作用于同一内存实例”。哪怕只有一行漏锁、一次值传递、一个未等待的 goroutine，-race 都可能在某次 CI 构建中突然炸出来。