sync.map仅适用于读多写少、键集稳定场景；不适用高频写入、需遍历或强一致性的场景，且load/store不保证线性一致性，range是快照式遍历，无len方法。
sync.Map 的适用场景和替代方案对比
sync.Map 不是通用并发 map 的首选，它专为「读多写少」的缓存场景设计。如果你频繁执行 Store 或 Delete，或者需要遍历全部键值对（比如做 LRU 驱逐），sync.Map 的性能反而可能比加锁的 map 更差 —— 因为其内部用 read + dirty 两层结构，写操作常触发 dirty 升级和复制。
常见误用是把它当普通并发字典用，结果发现 Range 不保证原子性、Len 没有内置方法、无法获取 keys 列表。真要支持复杂操作，老实用 sync.RWMutex 包一层原生 map 更可控。
正确初始化和基础操作写法
sync.Map 是零值安全的，不需要显式 new 或 make。直接声明即可使用：
var cache sync.Map
关键操作只有四个导出方法，必须严格按语义使用：
-
Load(key interface{}) (value interface{}, ok bool)：查缓存，不命中返回(nil, false) -
Store(key, value interface{})：覆盖写入，无返回值 -
LoadOrStore(key, value interface{}) (actual interface{}, loaded bool)：查不到才写，返回实际值和是否已存在 -
Delete(key interface{})：删除，不关心是否存在
注意：key 和 value 类型都是 interface{}，没有类型安全。如果缓存结构固定（如 string → *User），建议封装一层带类型断言的 wrapper，避免每次手动判断 ok。
为什么不能直接用 Range 做全量遍历或统计
Range 的回调函数在遍历时被多次调用，但期间其他 goroutine 可以并发 Store/Delete，所以它既不保证看到所有当前存在的 key，也不保证每个 key 只回调一次。官方文档明确说：「The Map's contents are not guaranteed to be consistent across multiple calls to Range」。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
这意味着：
- 不能靠
Range实现准确的Len()计数 - 不能用它做缓存清理扫描（比如按时间戳淘汰），因为可能漏删或重复删
- 如果真需要全量操作，要么加锁后转成普通
map，要么改用第三方库如golang.org/x/exp/maps（Go 1.21+）配合sync.RWMutex
LoadOrStore 在缓存加载中的典型误用
很多人用 LoadOrStore 实现「查不到就构造并存入」，但容易忽略构造过程本身不是原子的：
v, _ := cache.LoadOrStore(key, heavyConstruct())
这里 heavyConstruct() 总是会先执行，哪怕 key 已存在 —— 因为参数求值发生在函数调用前。正确写法是：
if v, ok := cache.Load(key); ok {
return v
}
v := heavyConstruct()
cache.Store(key, v)
return v
或者用双检锁模式封装，避免重复初始化。这点在初始化代价高（如解析配置、建连接）时特别关键。
sync.Map 的「并发安全」只针对其自身方法调用，不延伸到用户传入的构造逻辑。真正难的从来不是加锁，而是厘清哪段逻辑必须串行、哪段可以放行。
