Go内存模型关注goroutine间读写可见性而非存储位置；不靠同步原语无法保证安全；happens-before是定义操作先后关系的规则，非时间概念，如channel通信建立该关系。
Go 的内存模型不是讲“变量存在哪”，而是讲“一个 goroutine 写了，另一个 goroutine 什么时候能安全看到”。不靠同步原语，就永远没法保证。
happens-before 是什么，为什么它比“同时”重要
它是一套定义操作先后关系的规则，不是时间概念。比如 ch happens before <code><-ch 返回，意味着接收方一定能读到 42，且能看到发送方在发送前写入的所有变量值。
常见误区是盯着“两个 goroutine 是否几乎同时执行”，其实毫无意义——编译器重排、CPU 缓存、写缓冲区都会让“写入”延迟可见。真正起作用的是同步事件建立的顺序约束。
-
sync.Mutex.Unlock()happens before 另一个 goroutine 的mu.Lock()返回 -
sync.WaitGroup.Done()happens beforewg.Wait()返回 -
sync.Once.Do(f)中的f()happens before 所有once.Do(f)调用返回 - 普通变量赋值（如
a = 1）之间没有 happens-before 关系，除非被上述同步事件包裹
为什么不能混用 atomic 和普通读写
atomic 操作默认提供顺序一致性（Go 1.19+ 可选 relaxed/acquire/release），但前提是“全链路原子”。一旦你在某个 goroutine 用 atomic.StoreInt64(&x, 1)，另一个 goroutine 却用 x = 2 或 println(x)，就破坏了同步契约。
立即学习“go语言免费学习笔记（深入）”；
后果不是“偶尔错”，而是：可能读到撕裂值（如 64 位整数只更新了低 32 位）、可能看到旧值、可能触发未定义行为（race detector 会报 Data Race）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 计数器场景可用
atomic.AddInt64，但别把它当“线程安全的 int”来用 - 标志位（如
ready）若需配合其他数据（如data），必须用atomic.LoadAcquire+atomic.StoreRelease显式建序，否则data仍可能不可见 - 用
-race编译运行是底线，不是可选项
channel 和 mutex 哪个该优先选
channel 不是“用来传数据的管道”，它是“用来建序的同步机制”。它的语义比 mutex 更强：一次发送不仅保护了被发送的值，还隐含了发送前所有写入的可见性。
mutex 更适合保护一段临界区（比如修改结构体多个字段），而 channel 更适合解耦生产者/消费者、传递控制流或一次性信号。
- 多个 goroutine 需要协作更新同一组状态 → 用
sync.Mutex或sync.RWMutex - 一个 goroutine 生成结果，另一个等待并消费 → 用
chan T，哪怕只传struct{} - 需要广播、超时、select 多路复用 → channel 天然支持；mutex 不行
- map/slice 并发读写 → 必须加锁，
sync.RWMutex比sync.Mutex更合适
容易被忽略的底层事实：Go 不插硬件屏障，也不保你“直觉正确”
Go 编译器不会在普通赋值前后自动加 lfence/sfence，runtime 也不会替你把变量刷进主内存。所谓“可见”，全靠你显式调用的 sync 或 atomic 函数触发对应指令序列。
这意味着：runtime.Gosched() 不同步内存，time.Sleep() 不同步内存，fmt.Println() 更不保证——它们只是副作用，不是同步点。
最常踩的坑，是以为“我 sleep 了 1ms，对方肯定看到了”，或者“我在 main 里等了，goroutine 肯定执行完了”。只要没用 channel/mutex/WaitGroup/Once 建立 happens-before，就全是竞态。
