不能直接用 map + mutex 替代 sync.map，因为高频读多写少时 mutex 会成为瓶颈，而 sync.map 实现读无锁、写按需加锁；但内存占用高、不保证遍历顺序、len() 不可用。
为什么不能直接用 map + mutex 替代 sync.Map
因为高频读多写少的场景下，sync.RWMutex 会成为瓶颈：每次读都要抢锁（哪怕只是共享读），而 sync.Map 把读路径完全无锁化，写操作也只在必要时加锁。但代价是内存占用略高、不支持遍历顺序保证、不能直接用 len() 获取长度。
常见错误现象：fatal error: concurrent map read and map write —— 这说明你没用任何并发保护，或者误以为给 map 外面包了一层 mutex 就万事大吉（其实漏了读写竞争）。
- 适用场景：缓存、配置热更新、连接池元数据等「读远多于写」且 key 生命周期较长的服务内部状态
- 不适用场景：需要按插入顺序遍历、频繁全量遍历、key 数量极少（
-
sync.Map的LoadOrStore()是原子的，但注意它返回的是(value, loaded bool)，别漏判loaded
Load/Store/Delete 的参数和返回值怎么记牢
四个核心方法签名高度一致，记住「动词 + 首字母大写参数」就够了：Load(key interface{}) (value interface{}, ok bool)、Store(key, value interface{})、Delete(key interface{})、LoadOrStore(key, value interface{}) (actual interface{}, loaded bool)。
容易踩的坑：
立即学习“go语言免费学习笔记（深入）”；
-
Store()没有返回值，别想当然接ok；Delete()也不告诉你原来存不存在 - 所有 key 和 value 都是
interface{}，类型断言失败不会 panic，但会导致逻辑错乱——建议封装一层带类型的 wrapper，或用go:generate工具生成类型安全版本 -
LoadOrStore()中如果 key 已存在，传入的value被忽略，返回的是已存在的值；这点和map的m[key] = v语义不同
遍历时为什么不能边遍历边 Delete
Range(f func(key, value interface{}) bool) 不是快照遍历，而是边迭代边调用回调函数，期间允许其他 goroutine 修改 map，但当前迭代看到的 key/value 是调用 Range() 时刻已存在的（不一定是最新的 value）。
关键限制：回调函数里调用 Delete() 是安全的，但不能保证后续迭代不到刚删掉的 key —— 因为 Range() 内部没有锁，删除动作可能被后续迭代“错过”，也可能被重复看到（取决于底层分片结构和执行时机）。
- 正确做法：先
Range()收集要删的 key 到切片，再循环调用Delete() - 性能影响：
Range()时间复杂度是 O(n)，但 n 是当前存活 key 数量，不是底层数组容量；高频写入可能导致多次重哈希，拖慢遍历 - 没有
Keys()方法，别想着转成 slice 后再操作——必须靠Range()自己攒
sync.Map 和普通 map 在 GC 和内存上的实际差异
sync.Map 内部用了两层结构：read map（只读，无锁访问）+ dirty map（带锁，写时升级）。新写入先到 dirty，read 缺失时才从 dirty 加载；当 dirty 比 read 多出一定比例（默认是 dirty 全量提升为 read），会触发一次 copy。
这意味着：
- 短期高频写入后立即大量读，可能读到旧值（因为 read 还没同步 dirty）
- 每个 key-value 对额外携带一个
entry结构体指针，比原生 map 多 8~16 字节（取决于架构），小对象场景下内存放大明显 - GC 友好性一般：entry 里有指针字段，且 dirty map 里的 key/value 会被 retain 更久（直到下次 upgrade）
- 如果你的 key 是字符串且长度固定（比如 UUID），考虑用
unsafe.StringHeader避免重复分配，但这是高级技巧，得自己权衡
真正难处理的是 key 的生命周期管理——sync.Map 不提供弱引用或自动过期，超时清理必须自己基于时间戳 + 定期 Range() 扫描，这部分逻辑很容易写错或漏掉并发安全。
