sync.map不是普通map的并发安全替代品，而是专为读多写少、键生命周期不一场景设计的最终一致性结构，不支持for range、无len()、非原子遍历，性能在高并发读时优但频繁写时更差。
sync.Map 不能当普通 map 用
它不是 map[K]V 的并发安全替代品，而是为「读多写少 + 键生命周期不一」场景设计的特殊结构。直接拿它塞进原有 map 逻辑里，大概率掉坑里。
常见错误现象：sync.Map.Load 返回 (value, bool)，但很多人忽略第二个 bool 就直接用 value，结果拿到零值还以为数据存在；或者误以为 sync.Map.Range 是原子快照——其实遍历时其他 goroutine 仍可增删改，遍历结果不一致是正常的。
- 只在明确需要并发读写、且键集合动态变化（比如连接池、缓存淘汰）时才用
sync.Map - 如果只是多个 goroutine 同时读 + 单个 goroutine 写，用
sync.RWMutex包一层普通map更轻量、更可控 -
sync.Map的Store/Load操作不保证顺序，也不提供类似map的len()或delete语义
为什么 sync.Map 不支持 for range
因为它的底层是分片哈希表 + 延迟清理机制，没有全局锁，也没有统一的键数组或迭代器状态。Range 方法传入一个回调函数，每次调用都可能看到不同版本的数据——这不是 bug，是设计取舍。
使用场景：适合做「最终一致性」类操作，比如统计当前存活连接数、广播配置变更、触发清理任务，但不适合做「必须精确遍历所有键一次」的逻辑。
- 别在
Range回调里调用Load或Store——虽然不 panic，但会干扰内部清理节奏 - 如果真要枚举全部键值对并做原子性处理，老老实实用
sync.RWMutex+ 普通map，自己控制锁粒度 -
Range中修改的值不会反映到后续迭代中，哪怕同一 key 被多次Store，回调里也只看到某次快照
sync.Map 的性能陷阱在哪
它在高并发读场景下比加锁 map 快，但在频繁写或键冲突多时，反而更慢。核心开销在 dirty map 提升、entry 原子更新、以及 read map 缺失时的 double-check。
参数差异：sync.Map 没有初始化容量参数，也不能预分配空间；而普通 map 可以用 make(map[K]V, hint) 减少扩容重哈希。
- 写操作（
Store）比读（Load）贵得多，尤其首次写入某个 key 时会触发 dirty map 构建 - 大量短生命周期 key（比如 HTTP 请求 ID）会导致 read map 快速失效，频繁 fallback 到 dirty map，性能断崖下跌
- Go 1.19+ 对
sync.Map做了小优化，但没解决根本问题——它始终是「妥协方案」，不是通用解
替代方案怎么选：sync.Map vs RWMutex + map
多数时候，你真正需要的不是 sync.Map，而是一把读写锁包着的普通 map。它更直观、更容易测试、GC 更友好，而且只要你控制好写操作频率，性能差距微乎其微。
容易被忽略的地方：很多教程说「避免锁竞争就用 sync.Map」，但实际中 goroutine 往往不是卡在锁上，而是卡在内存分配、GC 或网络 IO 上。盲目换 sync.Map 可能掩盖真正的瓶颈。
- 如果写操作集中在初始化阶段（比如加载配置），之后全是读——用
sync.RWMutex+map，初始化后甚至可以去掉写锁 - 如果写操作分散但频率低（RWMutex 的开销几乎可忽略
- 只有当你确认 profile 显示
sync.RWMutex.Lock是热点，且写操作无法合并时，再考虑sync.Map
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
