Go 的 map 并发读写会 panic，因其非并发安全；sync.Map 适用于读多写少场景，但有 len 不支持、迭代受限等限制；手动加锁更可控。
为什么并发读写 map 会 panic
Go 的内置 map 不是并发安全的，一旦有 goroutine 在写（比如调用 map[key] = value 或 delete()），同时另一个 goroutine 在读（比如 v := map[key]），运行时大概率触发 fatal error: concurrent map read and map write。这不是概率问题，而是设计使然：底层哈希表在扩容、搬迁桶、调整结构时会修改指针和字段，没有加锁保护，多线程访问必然导致内存状态不一致。
sync.Map 适合什么场景
sync.Map 是标准库提供的并发安全替代方案，但它不是万能的“高性能 map 替代品”，而是一个为**读多写少**场景优化的数据结构：
- 读操作（
Load）几乎无锁，使用原子操作 + 副本机制，性能接近原生map - 写操作（
Store）会先尝试写入只读区（read），失败再加锁写入 dirty；首次写入后，后续对同一 key 的读会从 dirty 搬到 read，但不会自动同步全部 dirty 到 read - 不支持
len()，因为长度需遍历两个 map，无法原子获取；也不支持range迭代（只能用Range()回调） - 值类型必须是可比较的（满足
==），且不能是函数、map、slice 等不可比较类型
手动加锁比 sync.Map 更可控
如果业务逻辑明确、读写比例均衡，或需要 len()、迭代、自定义删除逻辑等，直接用 sync.RWMutex 包裹普通 map 往往更简单、更易测试：
var m = struct {
sync.RWMutex
data map[string]int
}{data: make(map[string]int)}
// 读
m.RLock()
v := m.data["key"]
m.RUnlock()
// 写
m.Lock()
m.data["key"] = 42
m.Unlock()
注意：RWMutex 的写锁会阻塞所有读，而 sync.Map 的写可能引发脏数据延迟可见；若存在大量写竞争，RWMutex 可能比 sync.Map 更快——因为后者内部仍要处理 read/dirty 切换开销。
立即学习“go语言免费学习笔记（深入）”；
容易被忽略的边界行为
几个上线后才暴露的坑：
-
sync.Map.Load()返回(value, ok)，但ok == false并不意味着 key 一定不存在——可能是 key 存在但值为零值（如int的0），需结合业务判断是否真缺失 -
sync.Map不会自动清理已删除的 key：即使调用Delete()，该 key 仍可能残留在 dirty map 中，直到下一次LoadOrStore()或Range()触发 clean 操作 - 不能把
sync.Map当作通用并发容器来嵌套使用，比如map[string]*sync.Map—— 外层 map 本身仍不安全，必须额外加锁
真正需要并发 map 时，先问自己：是不是非得用 map？能否用 channel + 单 goroutine 串行处理？有时候退一步，反而更稳。
