go内存模型核心是happens-before关系，决定读写可见性；共享变量需同步原语（channel、mutex等）保障安全；原子操作轻量但有前提，复杂场景优先用channel或mutex；-race检测器必备。
Go 语言的内存模型定义了 goroutine 之间如何通过共享变量进行通信，以及读写操作何时对其他 goroutine 可见。它不依赖底层硬件内存模型，而是提供一套明确、可预测的语义——核心在于 同步事件的先后关系，而非“同时”或“立即”。理解它，关键不是记住规则条文，而是掌握“什么操作能建立 happens-before 关系”，因为只有被该关系保证的写操作，才能被后续读操作可靠看到。
共享内存本身不是问题，缺乏同步才是
Go 允许多个 goroutine 读写同一变量，但这不意味着可以随意访问。没有同步机制时，编译器和 CPU 都可能重排指令、缓存值或延迟写入，导致一个 goroutine 看不到另一个刚写入的新值，甚至看到“撕裂”的中间状态（如 64 位整数只更新了低 32 位）。这不是 bug，而是未定义行为的体现。
常见误区是认为“变量是全局的 / 包级的 / 指针传递的”就天然线程安全——其实完全无关。真正起作用的是同步原语：
- channel 发送与接收：发送操作在接收操作开始前完成（happens-before）
- sync.Mutex.Lock/Unlock：Unlock 在后续 Lock 返回前完成
- sync.WaitGroup.Done/Wait：Done 在 Wait 返回前完成
- sync.Once.Do：Do 中的函数执行在返回前完成，且只执行一次
原子操作：轻量级同步，但有严格使用前提
sync/atomic 提供无锁的底层原子读写（如 LoadInt64、StoreInt64、CompareAndSwapInt64），适用于简单计数器、标志位、单个字段更新等场景。但它不提供内存屏障的完整语义，需手动配对使用：
立即学习“go语言免费学习笔记（深入）”；
- 用
atomic.Load*读，必须用atomic.Store*写（不能混用普通赋值） - 想保证“读到新值后，也能看到该 goroutine 之前写入的其他非原子变量”，需用
atomic.LoadAcquire+atomic.StoreRelease（Go 1.19+）显式指定内存序 - 普通
atomic.Load/Store在 Go 中默认提供顺序一致性（sequentially consistent），开销略高但语义清晰，日常够用
例如计数器：atomic.AddInt64(&counter, 1) 是安全的；但若想用原子变量作为“就绪标志”，并期望之后读取另一组数据，就必须确保这两者间有 happens-before，否则仍可能读到旧数据。
不要用原子操作替代设计，优先用 channel 和 mutex
原子操作易出错、难调试、可读性差。它适合性能敏感且逻辑极简的路径（如日志采样开关、引用计数）。复杂状态协同、多字段关联更新、需要条件等待的场景，应首选：
- channel：天然携带同步与通信，适合生产者-消费者、信号通知
- sync.Mutex 或 RWMutex：保护临界区，逻辑清晰，Go 运行时对其做了深度优化
- 结构体嵌入 sync.Mutex：把锁和数据绑定，避免忘记加锁
一个典型反例：试图用多个 atomic.Value 模拟带版本号的对象更新，结果因缺少整体原子性而出现状态不一致。这时用互斥锁包裹整个更新逻辑，反而更简单可靠。
验证与调试：别靠猜测
Go 的 -race 检测器是必备工具。它能在运行时发现数据竞争（data race）——即两个 goroutine 并发访问同一变量，且至少一个是写操作，又无同步约束。它无法检测逻辑错误（如锁粒度太粗），但能揪出绝大多数内存可见性隐患。
- 开发和 CI 中始终启用
go run -race或go test -race - 注意：race 检测器会显著降低性能，仅用于测试，不可用于生产环境
- 若检测到竞争，不要绕过它（如加 sleep 或 busy-wait），而是回归同步原语修复
