sync.Map声明无需make或字面量，零值即可用；它不支持[]语法、类型约束和range遍历，仅适用于读多写少场景。
sync.Map 声明方式和初始化要点
Go 语言里 sync.Map 不能像普通 map[string]int 那样直接用 := 声明并赋值字面量，它没有字面量语法，必须显式初始化。
常见错误是写成 var m sync.Map = map[string]int{"a": 1} 或 m := sync.Map{"a": 1} —— 这两种都编译不通过。
- 正确声明（零值可用）：
var m sync.Map，此时m已可直接调用Load/Store等方法 - 正确声明 + 类型别名简化：
type SafeMap sync.Map，之后用var m SafeMap - 不推荐在声明时“预填充”：需逐个
Store，例如m.Store("key1", "val1")
为什么不能用 make(sync.Map)？
sync.Map 不是引用类型，也不是运行时内置的 map 实现，它是个结构体，内部封装了两层 map（read + dirty）和互斥锁，所以不支持 make。
写 m := make(sync.Map) 会报错：cannot make type sync.Map。
立即学习“go语言免费学习笔记（深入）”；
-
make只适用于slice、map、chan这三种内置类型 -
sync.Map的零值是有效的、并发安全的，无需额外初始化步骤 - 如果误以为要
make，大概率是混淆了map[K]V和sync.Map的设计意图
什么时候该用 sync.Map，而不是 map + sync.RWMutex？
不是所有并发读写场景都适合 sync.Map。它的优势在「读多写少」且键集合变化不频繁的场景；劣势是内存占用高、遍历成本高、不支持 len()。
- 适用：
cache类场景（如请求 ID → 上下文映射）、配置热更新中的只增/只改键 - 慎用：
for range遍历频繁、需要精确长度统计、写操作占比 > 30% 的场景 - 替代方案更灵活：
map[K]V+sync.RWMutex更易控制锁粒度，也便于加监控或 hook -
sync.Map的Range是快照语义，遍历时可能漏掉新插入项，且无法中途break
sync.Map 的典型使用模式
避免把 sync.Map 当作通用 map 使用。它的 API 是函数式风格，没有索引操作符 []，所有访问必须走方法。
- 存：
m.Store(key, value)（覆盖写） - 取：
if v, ok := m.Load(key); ok { ... }，注意返回两个值 - 删：
m.Delete(key)，无返回值 - 遍历：
m.Range(func(key, value interface{}) bool { ... })，回调返回false可提前退出 - 不支持类型约束：key/value 都是
interface{}，类型断言不可避免
如果你需要强类型、高频遍历或确定性行为，sync.Map 很快会变成维护负担。它解决的是特定并发瓶颈，不是 map 的“线程安全升级版”。
