sync.Map适合读多写少场景的数据，如配置缓存、连接池元信息、用户会话状态快照；不适合高频增删改的实时聚合类数据。
sync.Map 适合存什么类型的数据
sync.Map 不是通用并发 map 的替代品，它专为「读多写少」场景设计。如果你的业务里 Load 操作远多于 Store（比如配置缓存、连接池元信息、用户会话状态快照），用 sync.Map 才有收益；反之，如果频繁增删改（如计数器实时聚合、消息队列中间状态），直接用 map + sync.RWMutex 更可控、更省内存。
为什么不能对 sync.Map 做 range 遍历
sync.Map 没有导出其内部 map，也不提供类似 for range 的迭代接口，这是刻意为之：它的底层是「只读 map + dirty map」双结构，遍历时无法保证一致性，且不承诺遍历顺序或原子性。你必须用 Range 方法传入回调函数处理每项：
var m sync.Map
m.Store("a", 1)
m.Store("b", 2)
m.Range(func(key, value interface{}) bool {
fmt.Println(key, value) // 输出可能无序，且不反映调用时刻的完整快照
return true // 继续遍历；返回 false 则中止
})
- 回调中修改
key或value不影响 map 本身（它们是副本） - 遍历期间其他 goroutine 的
Store可能不被看到，Delete可能被跳过 - 不要在回调里调用
m.Load/Store/Delete—— 可能导致死锁或 panic
LoadOrStore 和 LoadAndDelete 的典型误用
这两个方法看似“原子”，但语义容易混淆：
-
LoadOrStore(key, value)：若 key 存在，返回已有值和false；否则存入value并返回它和true。注意：它不会覆盖已存在值，也不会触发更新逻辑 -
LoadAndDelete(key)：返回当前值（若有）并删除 key；但如果 key 不存在，只返回零值和false，**不报错也不提示**
常见错误是拿 LoadAndDelete 当「安全取并删」用，却忘了检查返回的 bool：
立即学习“go语言免费学习笔记（深入）”；
if val, loaded := m.LoadAndDelete("session_id_123"); loaded {
// val 是真实旧值，可做清理逻辑
cleanup(val)
} else {
// key 本来就不在 map 里，不是 bug，是常态
}
sync.Map 的零值可用，但别混用指针
sync.Map 是结构体，零值即有效实例，无需 new 或 &sync.Map{}。但要注意：它**不支持嵌入到其他 struct 后直接以指针方式使用**——因为方法集只绑定在值类型上：
type Cache struct {
data sync.Map // ✅ 正确：字段是值类型
}
// 使用：
c := Cache{}
c.data.Store("x", 1)
// ❌ 错误写法（编译失败）：
type BadCache struct {
data *sync.Map // 方法无法通过 *sync.Map 调用
}
另外，sync.Map 的 key/value 类型是 interface{}，运行时无类型检查，建议用具名类型封装或加断言，避免传入 nil 指针导致后续 panic。
真正麻烦的不是怎么用，而是什么时候不该用 —— 它的内存开销比普通 map 高约 2–3 倍，且 GC 压力略大；小规模并发（map + RWMutex 往往更快更省心。
