sync.Map 专为读多写少、键值生命周期长的场景设计，不支持 range、len() 等操作，非普通 map 的线程安全替代品；高频并发读写应优先考虑 sync.RWMutex + 原生 map。
sync.Map 适合读多写少，但别把它当普通 map 用
sync.Map 不是线程安全版的 map，它压根没实现 range、不支持 len()、不能直接取地址、也不能用 for range 遍历。它的设计目标很窄：高频读 + 低频写 + 键值生命周期长。如果你只是想多个 goroutine 同时读写一个字典，又没做压测，大概率该用 sync.RWMutex 包一层原生 map，而不是硬切到 sync.Map。
常见错误现象：fatal error: concurrent map read and map write 出现后第一反应换 sync.Map——这往往治标不治本。真正该做的是确认是否真有并发写，还是只是读写混用没加锁。
- 使用场景：HTTP handler 中缓存用户会话（只增不删/极少更新）、配置热加载后的只读查询、指标聚合中 key 固定且写入间隔长
- 性能影响：首次读写会触发内部
read和dirtymap 的同步，后续读在read上无锁，但写入新 key 必须升级到dirty，代价比 mutex + map 高 2–3 倍 - 兼容性注意：
LoadOrStore返回值顺序是value, loaded bool，和Load一致；但Range回调函数参数是key, value interface{}，不是指针，改了没用
LoadOrStore 和 Store 行为差异极大，别默认替换
LoadOrStore 看似“有就返回，没有就设”，但它的“设”只发生在 key 完全不存在时；如果 key 在 read map 里存在但被标记为 deleted（比如之前调过 Delete），它不会重建，而是直接返回 nil/false。而 Store 会强制写入 dirty map，还会在下次 Load 时把 key 从 read 同步过去。
容易踩的坑：用 LoadOrStore 替代“先查再写”的逻辑，结果发现删过的 key 死活加不回来。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：需要“确保存在并获取值”，优先用
Load+Store组合；只有明确要“原子性地初始化一次”，才用LoadOrStore - 参数差异：
LoadOrStore(key, value)的value必须是具体值，不能是nil（否则 panic）；Store允许nil - 性能提示：频繁调用
LoadOrStore且 key 已存在，比纯Load多一次原子判断，开销略高
Range 不是遍历，是快照，而且没法中断
Range 不是迭代器，它内部会先锁定整个 sync.Map，复制当前 read 和 dirty 的全部有效 entry 到临时 slice，再解锁，最后逐个回调。这意味着：你无法在回调里删 key、不能提前退出、看到的数据可能已过期。
典型误用：想用 Range 找出所有过期 session 并清理——这会导致每次清理都锁全表，还可能漏删刚写入的 dirty key。
- 替代方案：需要定期清理，老老实实用
sync.RWMutex+ 普通map，配合定时器 +delete；或者把过期逻辑下沉到Load时检查时间戳 - 性能陷阱：
Range时间复杂度是 O(n)，n 是当前所有存活 key 数；如果 key 量级上万，单次调用可能卡住几十毫秒 - 注意点：回调函数内修改传入的
key或value变量，不影响 map 内部数据；也不能靠return中断遍历
为什么 len() 不可用？因为长度不是核心指标
sync.Map 没提供 Len() 方法，官方文档明确说“length is not a primary concern”。它内部两个 map（read 和 dirty）状态不同步，删掉的 key 可能还留在 read 里占位，dirty 里又有未提升的新增项。真要算长度，只能自己维护计数器，或用 Range 累加——但后者代价太高，且结果仍是快照。
容易忽略的地方：监控告警里写 if len(mySyncMap) > 10000 这种逻辑，根本编译不过；换成 Range 统计又引入延迟和不准，不如换个思路。
- 实际建议：监控维度改用“最近 1 分钟 Load 调用耗时 P95”或“Store 失败率”，比总长度更有意义
- 如果业务强依赖大小感知（比如限流），说明
sync.Map本身就不合适，应回退到带锁的map+ 原子计数器 - 注意：
sync.Map的零值是有效对象，无需new或make，直接声明就能用，这点常被忽略
