Go race detector仅在真实goroutine交错读写同一内存地址时报警；go test -race必须紧贴go test后、包路径前，如go test -race ./，位置错误则静默失效；竞态报告需关注内存地址一致性及goroutine归属，常见于未加锁map并发读写；本地不报线上崩因调度不可控，应强制重跑并用GORACE="halt_on_error=1"快速定位；修复后必须以-race零警告为唯一验证标准。
Go race detector 不是预言机，它只在两个 goroutine 真实交错读写同一内存地址时才报警；没跑过的路径、没逃逸的变量、没触发的调度时机，它一律沉默。
go test -race 命令位置写错就等于没开
race 检测器不是程序参数，而是编译器插桩指令，必须紧贴 go test 后、包路径前，否则静默失效：
- ✅ 正确：
go test -race ./、go test -race -v pkgname - ❌ 错误：
go test ./ -race（-race被当成本地路径参数）、go run main.go -race（-race变成你程序的 flag）
CI 中建议统一用 go test -race ./，避免因路径写法差异导致漏检。测试通过但线上崩，第一件事就是查这条命令有没有写对位置。
WARNING: DATA RACE 报告里真正要盯的三行
别被“Previous”“Current”字面顺序带偏——竞态本质是无序，关键看内存地址和 goroutine 归属：
立即学习“go语言免费学习笔记（深入）”；
- Read at
0x00c00001a240by goroutine 7 和 Previous write at0x00c00001a240by 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) }() }）就藏在这类位置
本地不报但线上崩，根本原因是调度不可控
竞态是否暴露，高度依赖 goroutine 调度时机。本地单核、低负载下容易“顺”，线上多核+高并发+GC 频繁，内存重排序和缓存不一致更容易撞上窗口：
- 别信“本地跑了 10 次都 OK”——加
-count=5或-count=10强制重跑，防测试缓存 - 用
GORACE="halt_on_error=1"让第一次竞态直接 panic，配合pprof快速定位阻塞点 - 测试里禁用
time.Sleep等靠时序控制的逻辑；改用sync.WaitGroup或select显式同步，确保所有 goroutine 真正执行并结束
修复后必须用 -race 验证，而不是靠“我觉得加了锁就安全”
加了 sync.Mutex、改用 atomic.AddInt64、甚至换成 chan，都不代表问题消失。唯一标准是 go test -race 零警告：
- 锁粒度不对：比如只锁了写，忘了读；或把 HTTP 调用、日志等耗时操作包进临界区，性能崩了但竞态仍在交界处
- atomic 不够用：字段更新带条件判断（如 “仅当旧值为 0 才设新值”），
atomic.CompareAndSwapInt64才是正确选择，不是所有整数都适合裸 atomic - 第三方库内部竞态：-race 一样会报，但堆栈停在你调用它的那一行，得顺着调用链往里查，不能只改自己代码
最常被忽略的一点：竞态可能发生在 init() 阶段，而你的测试根本没覆盖该包初始化——报告里会出现 runtime.goexit，需补显式初始化测试。
