go内存模型允许编译器在单个goroutine内对无依赖的变量赋值进行重排序，以优化性能；但若缺乏显式同步（如channel、mutex、atomic操作等），其他goroutine可能观察到违反代码顺序的读取结果。
go内存模型允许编译器在单个goroutine内对无依赖的变量赋值进行重排序，以优化性能；但若缺乏显式同步（如channel、mutex、atomic操作等），其他goroutine可能观察到违反代码顺序的读取结果。
在Go中，var a, b int 声明会在程序启动时将 a 和 b 初始化为 0（零值）。随后，在 f() 函数中看似顺序执行的 a = 1; b = 2;，并不保证对其他goroutine可见的写入顺序。关键在于：Go内存模型仅保证单个goroutine内部的语义一致性（即“as-if-serial”语义），而非跨goroutine的执行顺序可见性。
根据Go内存模型文档：
Within a single goroutine, reads and writes must behave as if they executed in the order specified by the program.
But: Because of this reordering, the execution order observed by one goroutine may differ from the order perceived by another.
这意味着：只要 f() 中后续代码不依赖 a 和 b 的赋值顺序（例如没有 if a == 1 { ... } 或 println(a, b)），编译器或CPU就可能将 b = 2 提前执行——比如因寄存器分配更优、缓存行对齐等原因。这种重排序完全合法且常见，并非bug，而是现代硬件与编译器优化的必然结果。
立即学习“go语言免费学习笔记（深入）”；
下面是一个可复现该现象的增强示例（添加循环和sleep提高观测概率）：
package main
import (
"fmt"
"runtime"
"time"
)
var a, b int
func f() {
a = 1
b = 2
}
func g() {
// 多次尝试增加捕获“b=2而a仍为0”的概率
for i := 0; i < 1000; i++ {
if b == 2 && a == 0 {
fmt.Printf("Observed: b=%d, a=%d (reordering detected!)\n", b, a)
return
}
}
fmt.Printf("Normal: a=%d, b=%d\n", a, b)
}
func main() {
runtime.GOMAXPROCS(2) // 确保多核调度可能性
go f()
g()
time.Sleep(time.Microsecond) // 短暂等待，避免main过早退出
}⚠️ 注意事项：
- 这不是“竞态条件”（race condition）的误报，而是未同步访问导致的定义明确但不符合直觉的行为；
- go run -race 不会报告此例为data race，因为g()中无写操作，且f()中两次写无数据依赖——但逻辑上仍存在同步缺失；
- 要确保顺序可见性，必须引入同步原语。例如使用 channel：
done := make(chan struct{})
go func() {
a = 1
b = 2
close(done) // 同步点：close happens-before receive
}()
<-done // 阻塞直到f完成所有写入
fmt.Println(b, a) // 必然输出 "2 1"或使用 sync.WaitGroup、sync.Mutex、atomic.Store 等。核心原则是：任何跨goroutine共享变量的读写，都必须通过Go内存模型定义的happens-before关系建立同步。
总结：Go不保证单goroutine内无依赖写操作对其他goroutine的顺序可见性；重排序是设计使然，而非缺陷。正确并发编程的关键，不是依赖代码书写顺序，而是主动构建同步契约——这是从“能运行”迈向“可验证正确”的必经之路。
