ready=true 不是发布：Go 内存模型真正要你保证什么

Fri, 22 May 2026 16:40:00 +0800

线上偶现一个很烦的 bug：配置已经加载了，日志也打印了“ready”，但另一个 goroutine 读到的还是旧值。

代码看起来没什么毛病：先写数据，再把 ready 置成 true。读的一侧先等 ready，再读数据。人脑看这段逻辑，很容易得出一个结论：既然 ready 已经是 true，前面的数据当然也该准备好了。

问题就在这里。

在 Go 里，ready=true 不等于发布。普通变量上的“先写后读”，也不等于 goroutine 之间有可见性保证。

并发安全不是让代码看起来有先后，而是让规范承认它有先后。

这篇是 Go 内存模型系列的第一篇。它不打算把你拖进 CPU 指令、缓存一致性协议和汇编细节里。我们先解决一个更常见、更工程化的问题：goroutine A 写了变量，goroutine B 什么时候保证能看到？

答案只有一个：两边要存在 happens-before 关系。

最危险的代码，通常看起来最顺

先看这段很多人都写过的代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


var data string
var ready bool

go func() {
 data = "payload"
 ready = true
}()

for !ready {
}
fmt.Println(data)

直觉上，写入顺序很清楚：data 先被赋值，ready 后变成 true。读的一侧又是看到 ready 才打印 data，似乎不会出错。