Go 的 map 默认不是并发安全的
直接写入或读取同一个 map 实例，只要发生在多个 goroutine 中且至少有一个是写操作，就会触发 panic —— 运行时会报 fatal error: concurrent map writes 或 concurrent map read and map write。这不是概率问题，是确定性崩溃。
根本原因：Go 的底层 map 实现没有内置锁，也没有原子操作保障；其扩容、哈希桶迁移等过程天然不满足多线程可见性和互斥性。
- 哪怕只是
map[key] = value和_, ok := map[key]同时跑，也可能崩 -
len(m)或range m也不安全——range本质是连续读，期间若另一 goroutine 写了，就可能读到中间态甚至 panic - 用
sync.RWMutex包一层可以解决，但要注意：读锁不能防止写操作在加锁前已开始；必须确保所有访问路径都走同一把锁
什么时候该用 sync.Map
sync.Map 是标准库提供的“为高并发读、低频写”场景优化的替代品。它不是普通 map 的线程安全封装，而是用了分片 + 原子指针 + 只读缓存等策略，牺牲了部分通用性来换并发性能。
- 适用场景：键集合相对固定（比如配置缓存、连接池 ID 映射）、读远多于写（100:1 以上才明显受益）
- 不适用场景：需要遍历全部键值对（
sync.Map没有range支持，只能用Range()回调，且不保证原子快照）、频繁增删、依赖map的原生语法糖（如m[k] = v） - 注意：
sync.Map的LoadOrStore返回的是value, loaded bool，不是普通map的三值形式；类型是interface{}，需自己断言
sync.Map 和普通 map + sync.RWMutex 性能差异在哪
差别不在“谁更快”，而在“谁更稳、谁更重”。基准测试显示：纯读场景 sync.Map 略优；中等写压力下，sync.RWMutex 包裹的 map 往往更可控；高频写则两者都可能成为瓶颈。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Map避免了全局锁，读操作几乎无锁，但每次写都要检查只读区、尝试原子更新、可能触发 dirty map 提升，逻辑更重 -
sync.RWMutex简单直接，读锁可重入、写锁排他，但所有读操作都要抢锁（哪怕只是读一个 key），竞争激烈时容易卡住 - 实测提示：如果写操作占比超过 5%，通常
sync.RWMutex更好理解、更好调试；sync.Map的内部状态（如misses计数）无法观测，出问题难定位
别踩这些坑
很多人以为用了 sync.Map 就一劳永逸，结果掉进隐性陷阱。
- 误把
sync.Map当普通map用：syncMap["key"]会编译失败，必须用Load/Store/LoadOrStore等方法 - 忽略类型转换开销：所有值都是
interface{}，存之前要装箱，取出来要断言，高频小对象（如int64）反而比带锁的原生map[int64]int64慢 - 误信“自动缩容”：
sync.Map不会主动清理只读区里的过期项，删除后仍可能被Range()遍历到（取决于是否触发了升级） - 忘记初始化：声明
var m sync.Map即可，但若用new(sync.Map)也行——不过没必要，它没指针接收者限制
真正需要并发安全时，先想清楚读写比例、数据生命周期、是否需要遍历，再选方案。硬套 sync.Map 不如老老实实用 sync.RWMutex，至少错得明白。
