Go race detector 报告读写冲突时怎么找真正共享变量

看到 WARNING: DATA RACE 时，真正要找的不是“哪一行先改”，而是两条访问栈最终落到了哪一块共享存储。先看读写双方的函数和文件行号，再看对应 goroutine 的创建位置，最后沿参数、闭包、指针或切片追到同一个对象；确认没有锁、channel 或原子操作建立同步后，才决定怎么修。

最稳的排查顺序是“访问栈 → 创建栈 → 共享存储 → 同步关系”。如果只盯着报告里的第一行，常会把调用者误当成共享变量，或者给局部副本加锁而留下真正的竞争。

先把 race 报告读成三层证据

先用和问题路径相同的测试触发报告。全包测试通常从 go test -race ./... 开始；如果冲突只在集成测试或真实负载出现，就要运行带 -race 的程序或构建产物。检测器只能发现运行时实际发生的竞争，测试没有走到的分支不会自动出现在报告里。

# 先跑会触发并发路径的测试
go test -race ./...

# 报告很长时保留文件，并去掉本机源码前缀
GORACE="log_path=/tmp/go-race/report strip_path_prefix=$PWD" go test -race ./...

报告通常包含三类线索：Read by goroutine 或 Write by goroutine 下的访问栈、另一条冲突访问栈，以及 Goroutine ... created at 下的创建栈。前两者回答“在哪里碰了数据”，创建栈回答“谁把并发任务放进来的”。

真正共享的是哪一块内存

回到报告行号后，沿数据流画一条很短的链：启动 goroutine 的变量 → 闭包捕获的值 → 方法接收者或参数 → 字段、map、切片底层数组。常见陷阱是每个 goroutine 都有自己的索引变量，但它们仍然通过指针或切片共享同一个元素；另一个高频问题是把 err 声明在外层，多个闭包用 = 写入它。

import "sync"

type Stats struct {
	value int // 这个字段由多个 goroutine 读写
}

func (s *Stats) Add(delta int) {
	s.value += delta // 写访问
}

func (s *Stats) Snapshot() int {
	return s.value // 读访问
}

func serve(s *Stats) {
	go func() {
		s.Add(1) // 闭包拿到同一个 Stats 指针
	}()
	_ = s.Snapshot() // 调用者也访问同一字段
}

这里的共享对象是 *Stats 指向的结构体，不是 serve 里的局部调用表达式。检查时可问自己三件事：两条栈是否能追到同一个接收者或底层数组？至少一边是否写入？访问之间是否有明确的 happens-before 关系？三个答案都成立，才是应该修的竞争。

按共享对象选择修复边界

如果对象需要被多个 goroutine 读写，最直观的方案是让字段和 sync.Mutex 一起归属对象，并在读写方法内部成对保护。若数据天然只应由一个 goroutine 拥有，则用 channel 传递所有权，调用方不要再直接摸内部状态。只有单个计数、标志或时间戳这类独立值，且业务允许原子语义时，才考虑 sync/atomic。

type Stats struct {
	mu    sync.RWMutex // 锁和被保护的数据放在同一对象
	value int64
}

func (s *Stats) Add(delta int64) {
	s.mu.Lock()
	defer s.mu.Unlock() // 保证提前返回时也释放锁
	s.value += delta
}

func (s *Stats) Snapshot() int64 {
	s.mu.RLock()
	defer s.mu.RUnlock() // 读快照与写入使用同一同步边界
	return s.value
}

不要只在调用者外面加一把“看起来相关”的锁，却让另一个入口绕过它；也不要把 map 换成带锁的包装后继续暴露原始 map。修复完成后重新跑原来的触发测试，并补一条能覆盖真实并发入口的测试，否则“没有报告”可能只是没有撞上那条路径。

把复现路径变成稳定检查

报告偶发时，先扩大触发机会：让测试重复调用同一入口、减少无关等待，并保留失败日志。GORACE="halt_on_error=1" 适合快速定位第一处竞争，log_path 适合 CI 留档，strip_path_prefix 只改善路径可读性；它们都不会改变共享关系，也不能代替同步。

最终检查清单很短：访问双方是不是同一对象；冲突是否至少包含一次写；创建栈是否揭示了隐藏的循环或回调；锁、channel 或 atomic 是否覆盖所有入口；测试是否真的执行了这条路径。按这五项回看，通常比从报告顶部逐行猜原因更快。

常见问题

race detector 报读写冲突，是不是读操作本身有问题？

通常不是。读本身可以合法，但它与并发写访问同一内存且没有同步，就形成数据竞争；要修的是共享关系和同步边界。

报告里的两个文件行号不同，怎么确认是同一个变量？

顺着参数、接收者、指针、切片和 map 的数据流回到对象定义。不同函数甚至不同文件，仍可能通过同一个指针或底层数组访问同一存储。

把 GORACE 的 halt_on_error 打开就能解决问题吗？

不能。它只让程序在报告第一处竞争后退出，方便缩小日志；修复仍需要改变所有权或补上覆盖全部访问入口的同步。