nil map 写入会立即 panic 而非触发 concurrent map writes；真正并发崩溃需 map 已初始化且多 goroutine 无同步地读写。sync.Map 非普通 map 替代品，有类型、性能及使用限制。
未初始化的 map 不会引发 concurrent map writes，只会立即 panic： assignment to entry in nil map；真正触发并发崩溃的，是已初始化但无同步保护的 map 被多 goroutine 同时读写。
为什么 nil map 写入不是并发问题
声明但未 make() 的 map 是 nil，底层指针为空。任何写操作（如 m[k] = v）在 runtime 层直接触发 panic，不经过哈希计算、不检查并发状态、不涉及 bucket 或扩容逻辑。
- 单 goroutine 下也会崩：
var m map[string]int; m["a"] = 1 - 结构体字段为
map类型，但构造函数里漏掉m.field = make(...)，同样崩 - 错误堆栈里若没出现
runtime.mapassign或hashWriting，基本可排除并发场景
concurrent map writes 真正发生的条件
只有当 map 已通过 make() 或字面量初始化，并且 ≥2 个 goroutine 在无同步下同时执行写操作（或读+写），才会触发 Go runtime 的并发检测机制。
- 典型错误：启动多个 goroutine 循环往同一个
make(map[string]int)写键值 -
len(m)、for range m、delete(m, k)全部算“访问”，只要混入写操作就构成竞争 - 崩溃堆栈中出现
runtime.mapassign、runtime.mapdelete或hash_lookup，说明 map 已分配内存，问题出在并发控制缺失
sync.Map 不能掩盖未初始化问题
sync.Map 的零值可用，但它的用途和约束与普通 map 完全不同——它不是普通 map 的“安全替代品”，而是专为特定场景设计的并发结构。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Map键值必须是interface{}，无法做类型推导，强制类型转换开销明显 - 没有原生
range支持，Range()是快照式回调，期间新写入不可见 - 高频写场景下，性能可能比
sync.RWMutex + map[string]int差 2–5 倍 - 误把
sync.Map当成普通map直接赋值（如sm := sync.Map{}; sm["k"] = "v"）会编译失败，因为接口不匹配
最容易被忽略的细节
即使你用了 sync.RWMutex 封装普通 map，仍可能因锁粒度或使用方式出错：
-
Range遍历时调用Set()会死锁（读锁未释放，又尝试获取写锁） - 返回内部
map引用（如func (s *SafeMap) Data() map[string]int { return s.m }），外部绕过锁直接操作，整个保护失效 - 只对赋值语句加锁，却忘了
delete()、len()或for range也需要锁覆盖
