go允许单goroutine内对无依赖赋值（如a=1、b=2）重排序以优化性能，本goroutine内不可观察；但跨goroutine时若无同步（如channel关闭），可能观测到b=2而a=0，因缺乏happens-before关系。
go 单 goroutine 内的赋值可能被重排，但你感知不到
编译器和 cpu 会对无数据依赖的写操作做重排序，只要不改变该 goroutine 内部的可观察行为。比如 a = 1 和 b = 2 之间没有读写依赖，且后续没用到这两个变量，那 b = 2 完全可能先于 a = 1 执行——但你在本 goroutine 里永远 print 不出异常，因为所有读取都发生在写入“完成之后”（逻辑上）。这不是 bug，是 go 内存模型明确允许的优化。
跨 goroutine 时重排会导致 a=0 而 b=2 这种反直觉结果
真正的问题出现在多个 goroutine 共享变量时。例如一个 goroutine 执行 a = 1; b = 2，另一个 goroutine 执行 print(b); print(a)，你完全可能看到 b == 2 但 a == 0。这是因为：
- 没有同步点，
b = 2的写入对另一 goroutine 可能已可见，而a = 1还卡在寄存器或 store buffer 里 - Go 不提供默认的顺序一致性（unlike Java’s
volatile），也不自动插入内存屏障 - 这种现象在 x86、ARM 等所有主流架构上都会发生，不是 Go 特有，但 Go 明确要求你显式建
happens-before
channel 关闭是最轻量且符合 Go 惯用法的同步方式
用 close(done) 配合 是建立 <code>happens-before 的最简洁手段，它天然满足：关闭前的所有写入，对接收方一定可见。相比 sync.Mutex 或 sync.Once，它零锁开销、无阻塞等待、语义清晰。
错误示范：done （带缓冲 channel 发送）不能替代 <code>close()，因为发送完成不保证之前写入已全局可见；正确写法必须是 close(done) + 单次接收。
atomic.Store/Load 适合单变量原子更新，不适合多字段顺序保证
sync/atomic 包能解决单个变量的可见性和原子性，比如用 atomic.StoreInt32(&a, 1) 替代 a = 1。但它无法保证两个 atomic 写之间的相对顺序对其他 goroutine 可见——atomic.StoreInt32(&a, 1) 和 atomic.StoreInt32(&b, 2) 仍可能被重排观察到。需要多字段强顺序时，必须用 channel、mutex 或 atomic.Value 封装整个结构体。
关键点在于：重排本身不可怕，可怕的是你以为“代码写了 A 再写 B，别人就一定先看到 B 再看到 A”。Go 把同步责任交还给你，而不是替你猜。最容易被忽略的，就是把“单 goroutine 逻辑正确”误当成“多 goroutine 下也安全”。
