Go 的 map 为什么不是并发安全的？如何正确使用？

结论：Go 的 map 为单 goroutine 性能设计，读写过程（扩容搬迁、桶内修改）不是原子的，并发读写会产生数据竞争。运行时对"检测到并发写"直接 fatal error（不可 recover 的进程崩溃），这是刻意选择：宁可崩掉也不让程序带着已损坏的哈希表继续跑。

展开：不安全根源：map 写操作可能触发扩容，渐进式搬迁期间桶处于半迁移状态；两个写者同时改桶头指针、一写一读看到不一致的溢出桶链表，都会让内部结构永久错乱。为什么不内置锁：绝大多数 map 使用是单线程的，内置锁让所有用户付同步成本，违背 Go"不为用不到的特性付费"的设计哲学。正确姿势按场景：1）读多写少——sync.RWMutex 包一层（或 sync.Map，其内部 read 路径无锁，适合键集合稳定或每键只写一次的场景）；2）分片锁（shard map）——高并发写热点时按 key hash 分 32/64 个桶各自加锁；3）消息传递——通过 channel 把 map 所有权收敛到单个 goroutine，"以通信共享内存"的 Go 哲学解法。易错点：fatal error 的检测是抽样式的（写路径置标志位），没崩不代表安全；用 -race 跑测试是发现并发 map 访问的可靠手段。

type SafeMap struct {
    mu sync.RWMutex
    m  map[string]int
}
func (s *SafeMap) Get(k string) (int, bool) {
    s.mu.RLock(); defer s.mu.RUnlock()
    v, ok := s.m[k]; return v, ok
}

追问方向：sync.Map 的 read/dirty 双 map 结构与适用边界、map 扩容为何是渐进式而非一次性。