go test -race 必须紧接 go test 后、包路径前，否则静默失效；它仅检测实际执行的并发内存访问，需足够多 goroutine 和逃逸变量才能触发，修复后必须用 -race 验证。
go test -race 为什么必须写对位置
因为 go test -race 是命令解析器按固定顺序识别的开关，-race 必须紧跟在 go test 后、包路径前，否则会被忽略——它不是程序参数，而是编译器插桩指令。
- ✅ 正确：
go test -race ./、go test -race -v pkgname - ❌ 错误：
go test ./ -race（被当成本地目录参数）、go run main.go -race（-race变成你程序的 flag） - 测试没报错 ≠ 没竞态：位置写错时，
-race静默失效，连 WARNING 都不会输出 - CI 中建议固定用
go test -race ./，避免因路径写法差异漏检
竞态检测器不报警的常见原因
go test -race 不是静态扫描，它只监控**实际执行到的并发内存访问路径**。没跑过的分支、没逃逸的局部变量、没真正共享的值，它一律不管。
- 测试里只启了 2 个 goroutine 跑一次
c++→ 很可能错过竞态，建议设-count=1并发数拉到 50+，多轮触发 - 共享的是栈上未逃逸的
int（比如循环里定义又没传出去）→-race压根不跟踪，得让它“逃逸”到堆（如取地址传给 goroutine） - 用了
sync.Map或atomic但没覆盖全部读写路径 → 比如某个if分支绕过了原子操作，那条路径仍可能竞态 - 竞态发生在
init()阶段，而测试没显式触发该包初始化 → 报告里会出现runtime.goexit，需补初始化测试
看懂 DATA RACE 报告的关键线索
报告不是告诉你“谁先谁后”，而是指出「同一地址被两个 goroutine 访问，且无同步约束」——重点看冲突地址和调用栈归属，而不是时间标签。
-
Read at 0x00c00001a240 by goroutine 7和Previous write at 0x00c00001a240 by goroutine 6→ 地址一样，说明是同一个变量，比如cache.go:23的m["key"]读 vscache.go:31的写 - 如果栈里出现
runtime.mapaccess1_faststr或runtime.mapassign_faststr→ 基本锁定是未加锁map并发读写 -
Goroutine 7 (running) created at: main.TestCacheConcurrent() cache_test.go:45→ 直接定位到启动 goroutine 的测试行，闭包捕获变量（如for i := range xs { go func() { use(i) }() }）就藏在这类位置 - 别信
Previous write的“previous”字面意思——goroutine 调度不可控，它只是检测器记录的先后，本质是顺序不确定
修复后必须重跑 -race 验证
加了 sync.Mutex、改用 atomic.AddInt64、甚至换成 chan，都不代表问题消失。竞态是否真被消除，唯一标准是 go test -race 零警告。
立即学习“go语言免费学习笔记（深入）”；
- 锁没加对范围：比如只锁了写，忘了读；或锁了大段逻辑（含 HTTP 调用），导致性能崩但竞态仍在读写交界处
- 原子操作类型不匹配：对
int用atomic.LoadInt32会 panic；对结构体字段单独原子操作，但其他字段仍裸露 - channel 缓冲区满后继续
send→ 不是 data race，但会阻塞或 panic，-race不管这类问题 - 修复后务必跑
go test -race -count=1 ./，避免测试缓存跳过实际执行
