go语言允许编译器和处理器在单个goroutine内对无依赖的内存写入操作进行重排序，只要不改变该goroutine内部的语义；但若缺乏显式同步（如channel、mutex、atomic或sync.waitgroup），其他goroutine可能观察到违反代码顺序的值更新。
go语言允许编译器和处理器在单个goroutine内对无依赖的内存写入操作进行重排序，只要不改变该goroutine内部的语义；但若缺乏显式同步（如channel、mutex、atomic或sync.waitgroup），其他goroutine可能观察到违反代码顺序的值更新。
在Go内存模型中，“happens-before”关系是定义并发安全性的核心概念。虽然Go保证单个goroutine内程序顺序的语义一致性（即对同一goroutine而言，a = 1; b = 2; 的执行效果必须等价于按此顺序执行），但这并不强制硬件或编译器实际按文本顺序发出指令——只要重排序不影响该goroutine自身的可观察行为。
例如，在以下代码中：
var a, b int
func f() {
a = 1
b = 2
}
func g() {
print(b)
print(a)
}
func main() {
go f()
g()
}尽管 f() 中 a 先赋值、b 后赋值，但由于：
- a 和 b 之间无数据依赖（b 的赋值不读取 a），
- f() 在赋值后未再访问这两个变量，
- 主goroutine g() 与 f() 之间没有任何同步原语（如 channel send/receive、sync.Mutex.Lock()、atomic.Store* 等），
因此编译器可合法地将 b = 2 提前执行（例如因寄存器优化或缓存行对齐等原因），而主goroutine可能在 f() 尚未完成 a = 1 时就已读取到 b == 2 和 a == 0 —— 这正是Go内存模型明确允许的“非同步下的乱序可见性”。
立即学习“go语言免费学习笔记（深入）”；
⚠️ 注意：这不是“bug”，而是现代CPU架构与编译器优化的必然结果。C/C++/Java/Rust等主流语言在缺乏同步的前提下，同样存在类似行为。
✅ 正确做法是引入明确的同步点。以下是几种典型修复方式：
1. 使用 channel 实现顺序保证（推荐，符合Go惯用法）
func main() {
done := make(chan struct{})
go func() {
a = 1
b = 2
close(done) // 同步点：关闭channel意味着所有写入已完成
}()
<-done // 阻塞等待，确保 a,b 赋值完成
print(b) // 必为 2
print(a) // 必为 1
}2. 使用 sync.Mutex 保护共享变量
var mu sync.Mutex
func f() {
mu.Lock()
a = 1
b = 2
mu.Unlock()
}
func g() {
mu.Lock()
print(b)
print(a)
mu.Unlock()
}3. 使用 sync.Once 或原子操作（适用于初始化场景）
var once sync.Once
func initAB() {
a = 1
b = 2
}
// 在需要时调用：once.Do(initAB)? 总结：Go不会为无同步的并发访问自动插入内存屏障。开发者必须主动建立 happens-before 关系——通过 channel 通信、互斥锁、原子操作或 WaitGroup 等同步原语，才能确保一个goroutine的写入对另一个goroutine“可见”且“有序”。忽视这一点是并发Bug（如竞态、脏读、部分初始化）的主要根源。
