sync.Map本身已并发安全，无需额外加锁即可直接调用Load、Store、Delete、Range等方法；其内部通过原子操作、读写分离（read/dirty map）和细粒度锁实现同步。
sync.Map 本身已并发安全，无需额外加锁
直接调用 Load、Store、Delete、Range 等方法即可在任意 goroutine 中安全使用，不需要包一层 sync.Mutex 或 sync.RWMutex。这是 sync.Map 的设计前提——它内部已通过原子操作、读写分离（read map / dirty map）和细粒度锁完成同步。
常见错误是“画蛇添足”：比如把 sync.Map 塞进一个结构体里，再给整个结构体加锁：
type Config struct {
mu sync.RWMutex
m sync.Map // ❌ 完全没必要，反而增加锁开销
}
这不仅没提升安全性，还引入了不必要的调度延迟和锁竞争。
Load/Store 方法参数必须是 interface{}，注意类型转换成本
sync.Map 的所有方法都以 interface{} 接收 key 和 value，这意味着每次调用都会发生接口值构造（含内存分配），尤其当 key 是小整数或固定字符串时，会带来可测量的分配压力。
立即学习“go语言免费学习笔记（深入）”；
- 高频场景下，避免用
int或struct{}作 key；优先用string（常量字符串零分配）或预分配的*int - 读取后若需断言为具体类型，如
v, ok := m.Load("count").(int)，失败时 panic 不会被捕获；建议用ok判断 + 显式类型检查 - 若 value 是指针或大结构体，
Store存的是副本还是地址？答案是：存的是 interface{} 包装后的值，原值修改不影响 map 内容 —— 所以存指针更省拷贝，但要确保生命周期可控
Range 遍历不是原子快照，且无法中途 break
Range 方法传入一个回调函数，它会在内部锁住 dirty map 的瞬间拷贝一份迭代器，但遍历过程本身不持锁；因此：
- 遍历时其他 goroutine 仍可
Store或Delete，你可能看到部分新写入的 key，也可能看不到刚删掉的 key - 回调函数返回
false可提前退出，但不能用break或return直接跳出 —— 必须靠函数返回值控制 - 遍历顺序无保证，
sync.Map不保证 key 的插入/访问顺序，也不排序 - 如果需要强一致性遍历（例如导出全量状态），应改用
sync.RWMutex + map，并手动加读锁后遍历原生 map
写密集场景下 sync.Map 可能比 Mutex+map 更慢
sync.Map 的优势只在「读远多于写」时成立。一旦写操作频繁（尤其是反复更新同一 key），它会不断将 read map 升级为 dirty map、触发数据迁移，导致：
- 内存占用持续增长（旧 read map 暂不回收，依赖 GC）
- 每次
Store都需检查是否需升级，带来额外分支判断 - 多个 goroutine 同时写同一 key 时，锁竞争集中在 dirty map 的单一互斥锁上，退化为类似
sync.Mutex + map
实测中，若写占比超过 20%，尤其 key 集中在少量几个时，sync.RWMutex + map 往往吞吐更高、GC 压力更小。这时候别迷信 “标准库自带就一定好”。
真正容易被忽略的是：sync.Map 没有提供「存在则更新否则跳过」这类原子组合操作（比如 CAS 式的 LoadAndStore），也没有 Len() 方法。需要计数或条件更新时，往往得回退到加锁方案，或者自己封装一层带状态的 wrapper。
