nil map写入立即panic，与并发无关；concurrent map writes仅发生于已初始化map被多goroutine无同步读写。
未初始化的 map 本身不会导致 concurrent map writes，它连并发都算不上——写入就直接 panic：assignment to entry in nil map。
为什么 nil map 写入会立即崩溃，和并发无关
Go 中声明但没调用 make() 的 map（比如 var m map[string]int）底层指针为 nil。任何写操作（m[k] = v、delete(m, k)）在 runtime 层直接触发 panic，不走哈希计算，也不进 bucket 分配逻辑。
常见踩坑点：
-
struct字段声明为map类型，但构造时忘了make() - 函数返回
*map或map指针，分支里漏了初始化 - 误以为
sync.Map的零值能“修复”普通 map 的 nil 问题（不能，sync.Map零值可用，但普通 map 不行）
concurrent map writes 只发生在已初始化的 map 上
真正报 fatal error: concurrent map writes 或 concurrent map read and map write，说明 map 已经被 make() 过，底层结构已分配，只是多个 goroutine 在无同步下同时访问。
立即学习“go语言免费学习笔记（深入）”；
关键识别方式：崩溃堆栈里出现 runtime.mapassign、runtime.mapdelete 或 hash_lookup —— 这些函数只在 map 已初始化后才可能被调用。
典型场景：
- 多个 goroutine 同时执行
m[k] = v - 一个 goroutine
for range m，另一个 goroutinem[k] = v（range是读操作，也需同步） - 调用了
len(m)或delete(m, k)，同时有其他 goroutine 在写
用 sync.RWMutex + 普通 map 是最可控方案
比起 sync.Map，sync.RWMutex + 泛型 map 更灵活、性能更可预期，尤其适合写较多或需遍历的场景。
实操要点：
- 锁必须包住整个 map 操作，不能只锁赋值那行（例如
s.mu.Lock(); s.m[k] = v; s.mu.Unlock()） -
Range期间不能调Set—— 回调内再加写锁会死锁 - 不要暴露原始 map（如返回
s.m），否则外部绕过锁直接操作，锁形同虚设 - 读多写少时用
RLock()，写操作必须用Lock()
sync.Map 不是“自动安全”的银弹
sync.Map 零值可用，但接口是 interface{} 键值，没有泛型支持；且 Range 是快照式回调，期间新写入不可见。
它适合的场景很具体：
- 键集合基本固定，大部分是
Load和LoadOrStore - 写频率低（比如配置热更新、连接元信息缓存）
- 不想自己管理锁，且能接受类型擦除开销
不适合：
- 需要
for range全量遍历并保证实时性 - 频繁
Delete或批量初始化（sync.Map没有Clear，也没法预分配容量） - Go 1.21+ 项目中键值类型明确 —— 此时
sync.RWMutex+ 泛型 map 更推荐
最容易被忽略的一点：无论选哪种方案，map 字段在结构体里都得显式初始化，sync.Map 的零值可用 ≠ 普通 map 可以跳过 make()。
