go内存模型只定义多goroutine间读写同一变量时的可见性与顺序性契约，即读操作能否观察到写操作的修改；它不涉及内存分配、gc、对齐等底层细节，未同步的并发读写将导致数据竞争或陈旧值。
什么是Go内存模型，它到底管什么
Go内存模型不是讲堆怎么分配、GC怎么扫，它只回答一个问题：当两个goroutine分别读和写同一个变量时，读的那一方能不能看到写的值？ 它不保证“一定看到”，而是定义“在什么条件下能保证看到”。换句话说，它是关于可见性（visibility）和顺序性（ordering）的契约，不是自动同步机制。
- 它不管变量存在哪（栈 or 堆），也不管逃逸分析结果
- 它不介入垃圾回收、内存对齐、指针算术等底层细节
- 它唯一关心的是：读操作
r是否能观察到写操作w对变量v的修改
不加同步就跨goroutine读写变量，会发生什么
直接读写共享变量，大概率会看到陈旧值、部分更新值，甚至触发 data race 检测器报错——这不是“偶尔出错”，而是语言明确禁止的行为。Go运行时（带 -race）和编译器会在构建期/运行期主动揪出这类问题。
- 现象：一个goroutine执行
a = 1; b = 2，另一个goroutine可能看到a==0, b==2（重排序+缓存不一致） - 原因：CPU指令重排、编译器优化、多核缓存未同步，Go不做隐式屏障
- 典型错误写法：
var done bool; go func(){ done = true }(); for !done {}—— 这个循环可能永远不退出
用channel还是sync.Mutex来建立happens-before
两者都能建立先行发生关系，但语义和适用场景完全不同：channel强调通信，Mutex强调互斥。选错会导致逻辑错位或性能浪费。
-
channel：发送操作ch happens-before 对应的接收操作 <code>；适合传递数据、协调生命周期、解耦生产/消费 -
sync.Mutex：mu.Lock()和mu.Unlock()构成临界区边界；适合保护一段状态（如计数器、map、结构体字段） - 别混用：用
channel去保护一个map写入，不如用sync.RWMutex；反过来，用Mutex传递消息，代码会臃肿且易死锁 - 性能提示：频繁争抢的
Mutex比无缓冲channel开销更低；但channel天然支持超时、select多路复用，Mutex不行
为什么main函数初始化后启动的goroutine能看到全局变量
因为Go内存模型有一条硬性规则：main 函数开始执行 happens-before 所有由它直接启动的 goroutine。这意味着你在 main 里初始化的包级变量、切片、map，在子goroutine中首次读取时，一定能看见完整、已初始化的值。
- 但这条规则**不递归生效**：goroutine A 启动 goroutine B，B 并不自动“看到”A写入的局部变量（除非通过channel或锁显式同步）
- 常见误解：以为
var conf Config; func init(){ conf = load() }就够了——其实够，但仅限于init和main的顺序，不能替代运行时的并发同步 - 陷阱：如果
conf是指针或包含指针字段，且后续被多个goroutine修改，仍需同步；初始化完成 ≠ 后续访问安全
实际写代码时，最常被忽略的不是“要不要同步”，而是“同步的边界是否覆盖全部相关读写”。比如只锁了写，忘了读也要进临界区；或者用 atomic.LoadUint64 读，却用普通赋值写——这仍然构成 data race。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
