Go的-race检测器仅在运行时监控多goroutine对共享内存的非同步读写，通过插桩记录访问轨迹并实时比对，典型场景包括全局变量++、未加锁map读写、结构体字段竞写、闭包变量捕获等；启用需编译和运行均加-race，不可用于生产。
Go build -race 会检测哪些代码
Go 的 -race 检测器只在运行时监控对共享内存的**非同步读写访问**，前提是这些操作发生在多个 goroutine 中。它不分析代码逻辑，也不预测竞争，而是靠插桩（instrumentation）在每次内存读/写时记录调用栈和 goroutine ID，再实时比对是否发生“同一地址、不同 goroutine、无同步约束”的并发访问。
典型触发场景包括：
- 两个 goroutine 同时对一个全局
int变量做++ - 一个 goroutine 写
map，另一个 goroutine 读或遍历该map（未加锁） - 结构体字段被多个 goroutine 直接读写，且该结构体未用
sync.Mutex或atomic保护 - 闭包中捕获的局部变量被多个 goroutine 异步访问（比如
for i := range s { go func() { use(i) }() }中的i）
如何正确启用 race 检测
必须在编译和运行阶段都启用 -race，仅测试时加不行，仅构建时加也不行——因为检测逻辑嵌入在生成的二进制中。
常见有效方式：
- 运行测试：
go test -race ./...（推荐，覆盖单元测试路径） - 构建可执行文件：
go build -race -o app main.go，再运行./app - 运行单个命令：
go run -race main.go（适合快速验证小例子）
注意：-race 会显著增加内存占用（约 5–10 倍）和运行时开销（2–5 倍），**不能用于生产环境**，仅限开发与 CI 阶段使用。
race 报告里关键字段怎么看
当检测到竞争时，Go 会打印类似下面的报告：
==================
WARNING: DATA RACE
Read at 0x00c000010240 by goroutine 7:
main.main.func1()
/tmp/main.go:10 +0x39
Previous write at 0x00c000010240 by goroutine 6:
main.main.func2()
/tmp/main.go:14 +0x39
==================
重点看三部分：
-
Read at ... by goroutine N和Previous write at ... by goroutine M：说明是哪两个 goroutine 在争抢同一内存地址 - 函数名和行号（如
main.main.func1()和/tmp/main.go:10）：定位到具体语句，注意匿名函数的命名规则（func1,func2是按定义顺序编号的） - 地址（如
0x00c000010240）：通常不用手动解，但可用于交叉验证是否为同一变量（比如两个字段偏移接近，可能是同一结构体的不同字段）
如果报告里出现 runtime.mapassign 或 runtime.mapaccess1，基本可断定是未加锁的 map 并发读写。
容易被忽略的 false negative 场景
-race 是动态检测，不是静态分析，所以它**只能发现实际执行到的竞争路径**。以下情况它大概率检测不到：
- 竞争逻辑存在于未被执行的分支中（比如
if debug { ... }里的并发写，而debug为false） - goroutine 启动后因调度延迟或条件判断根本没跑起来，导致读写没真正并发发生
- 使用了
sync/atomic但操作类型不匹配（例如对int64用atomic.LoadUint32）：这属于未定义行为，race 不报，但程序可能崩溃 - 通过反射或
unsafe绕过正常内存访问路径（如直接操作指针地址），race 插桩无法覆盖
也就是说，没报 race ≠ 没有数据竞争，只是这次运行没撞上。真正可靠的并发安全，得靠设计（channel / mutex / atomic）而不是依赖检测器兜底。
