sync.Map 仅适用于读多写少、键生命周期长的场景，如缓存；盲目替代普通 map 可能降低性能并掩盖并发 bug。
直接说结论： sync.Map 不是万能的线程安全替代品，它只适合“读多写少 + 键生命周期长”的场景；盲目用它替换普通 map 反而可能降低性能、掩盖并发 bug。
什么时候该用 sync.Map？
它专为以下典型场景设计：
- 缓存类结构（如请求上下文缓存、连接池元信息），读操作远多于写（比如 99% 是
Load，1% 是Store） - 键集合基本稳定，不频繁增删（
sync.Map的Delete不会立即回收内存，且遍历成本高） - 无法提前预估 key 数量或并发写入模式（避免手动加
sync.RWMutex锁整个 map） - 不需要原子性地批量操作（如“若 key 不存在则插入并返回默认值”这类逻辑仍需自己用
LoadOrStore组合）
sync.Map 常见误用和坑
这些错误会导致行为不符合预期，甚至隐藏数据竞争：
- 把
sync.Map当作普通map用：比如循环中反复Range+ 修改，但Range不保证看到所有最新写入（它基于快照机制） - 误以为
Load返回的是可寻址值：返回的是interface{}拷贝，对它取地址或修改不会影响 map 内部值 - 在
Range回调里调用Delete或Store：虽然不 panic，但该次遍历看不到后续新增项，已删除项仍可能被遍历到（文档明确说明“callback may be called concurrently with other operations”） - 用
sync.Map存储指针或 struct 并期望字段级并发安全：它只保证 map 自身操作安全，内部值的并发访问仍需额外同步
正确用法示例与关键 API 对比
对比标准操作，注意参数类型和语义差异：
var m sync.Map
// ✅ 正确：存 string 类型值（自动装箱）
m.Store("user_id_123", "active")
// ✅ 正确：读取并判断是否存在
if val, ok := m.Load("user_id_123"); ok {
fmt.Println(val) // val 是 interface{}，需类型断言
}
// ✅ 正确：原子性地“查无则设”，避免竞态
val, loaded := m.LoadOrStore("config_timeout", 30)
// ❌ 错误：不能像普通 map 那样直接赋值
// m["key"] = "value" // 编译失败
// ❌ 错误：不能用 range 遍历获取键值对切片
// for k, v := range m { ... } // 编译失败
真正需要遍历时必须用 Range，且 callback 内不可依赖顺序或完整性：
m.Range(func(key, value interface{}) bool {
// key 和 value 都是 interface{}，需断言
if k, ok := key.(string); ok && strings.HasPrefix(k, "user_") {
fmt.Println("found:", k)
}
return true // 继续遍历；返回 false 则中断
})
最易被忽略的一点：sync.Map 的零值是可用的，无需显式 new 或 &sync.Map{}；但它内部使用惰性初始化，首次 Store 才分配资源——这个延迟在压测初期可能造成抖动。
