Go atomic值混用普通读写引起数据竞争的修复清单

Go 里把写操作改成 sync/atomic，并不代表这个变量从此安全了。只要另一个 goroutine 仍然通过普通表达式读取或写入同一地址，原子访问和非原子访问就可能形成数据竞争。修复的核心不是“多加一次 Load”，而是让同一个共享状态只保留一种同步边界。

先把同一变量的访问路径画清楚

先不要急着把所有表达式替换成 Load。以一个状态字段为中心，搜索它的赋值、比较、格式化、日志打印和传参位置，再标出每条路径采用的是普通读写、原子操作还是互斥锁。最容易漏掉的是“写已原子化、读仍然普通”的半迁移状态。

例如下面的读取会绕过原子边界，即使写入方调用了 StoreInt64 也不够安全：

var ready int64

// 写路径使用原子操作，避免单次写入被拆分。
atomic.StoreInt64(&ready, 1)

// 错误示例：读取仍是普通访问，与上面的原子写混用。
if ready == 1 {
	startWorker()
}

如果这个判断只发生在单 goroutine 内，风险可能暂时不显眼；一旦它与写路径并发，-race 就有机会报告冲突。把读取改为 atomic.LoadInt64(&ready) 只是第一步，还要继续搜索是否有其他普通写入。

按变量类型选择修复模型

修复时先判断共享数据的形状。一个整数计数器不需要为了读取而引入大锁；但由状态、时间戳和错误信息组成的结构体，也不能把三个字段分别原子化后就假定它们构成一个一致快照。

单值状态可以封装成小对象，减少调用方忘记同步方式的机会：

type Gate struct {
	// typed atomic 让读写入口固定为 Load 和 Store。
	ready atomic.Bool
}

func (g *Gate) Open() {
	// Store 只改变一个布尔状态，不承担其他字段的一致性。
	g.ready.Store(true)
}

func (g *Gate) IsOpen() bool {
	// 读取也必须走同一个原子对象，不能返回裸字段。
	return g.ready.Load()
}

迁移时重点检查四个边界

1. 复合读改写：Load 后再 Store 不是天然的复合原子操作。需要条件更新时使用 CompareAndSwap，或直接用互斥锁包住整个业务判断。
2. 对象复制：typed atomic 和 atomic.Value 在首次使用后不应复制。把包含它们的结构体按值传参、放入会复制的容器，都要重新确认生命周期。
3. 指针与快照：atomic.Value 适合替换完整配置快照，不代表快照内部的 map 或切片可以被另一个 goroutine 原地修改。
4. 对齐与所有权：旧式 LoadInt64 等 API 在特定平台要关注 64 位对齐；新代码优先把 typed atomic 放在明确的结构体字段中。

如果业务状态必须同时满足“状态为 ready 且错误为空”，优先把两个字段放在同一把锁或同一个不可变快照里，避免读到跨时刻组合。

用 race 检查修复是否真的闭环

修复后先跑专门覆盖该状态的并发测试，再跑全包竞态检测：

# 运行竞态检测，覆盖所有包和测试路径。
go test -race ./...

# 只跑共享状态相关测试，便于快速复查迁移结果。
go test -race ./... -run TestGate

若报告仍指向原字段，通常是遗漏了日志、序列化或测试夹具中的普通访问；若报告消失但状态仍不一致，则可能是模型选择错误，而不是单纯的数据竞争。把“变量—访问点—同步模型—测试覆盖”记录成清单，下一次改字段时就不会重新掉回半原子状态。

常见问题

只把写操作换成 atomic.Store 就够了吗？

不够。同一地址的并发读取也必须是原子的，或者与写入共同受同一把锁保护；普通读仍可能与原子写形成混用。

atomic.Load 后修改再 Store 能代替 Mutex 吗？

不能直接等价。只要中间存在条件判断或多个字段，就要考虑 CompareAndSwap 循环、Mutex 或不可变快照。

为什么 race 没报错，代码仍要统一访问方式？

竞态检测依赖测试覆盖，没报错只说明已执行路径未观察到冲突。统一访问模型是代码边界，测试是对边界的复查。