nil map写入立即panic，与并发无关；并发崩溃仅发生于已初始化map被多goroutine无同步读写。runtime通过hashWriting标志检测并发写，读操作因可能遭遇扩容等中间态亦会panic。
未初始化的 map 本身不会导致并发崩溃，但会立即 panic —— 和并发无关；真正引发 fatal error: concurrent map writes 的，是已初始化的 map 被多个 goroutine 无同步地读写。
为什么 nil map 写入会 panic，但不是“并发崩溃”
Go 中声明但未调用 make() 的 map 是 nil，它的底层指针为 nil。此时任何写操作（如 m[k] = v）会在 runtime 层直接触发 panic: assignment to entry in nil map，不经过哈希计算、不涉及 bucket、更不触发并发检测。
这种 panic 是单 goroutine 立即发生的，和是否并发完全无关。常见错误场景：
-
var m map[string]int; m["a"] = 1—— 即使只在一个 goroutine 里执行也崩 - 结构体字段声明为
map类型但忘记在new()或构造函数中make() - 函数返回
map指针，但初始化逻辑被条件分支跳过
并发崩溃只发生在已初始化的 map 上
只有当你已经执行过 m := make(map[string]int 或等价字面量后，再由 ≥2 个 goroutine 同时执行写操作（或读+写），才会触发 Go runtime 的并发写检测机制，报出 fatal error: concurrent map writes 或 concurrent map read and map write。
立即学习“go语言免费学习笔记（深入）”；
关键点：
- 崩溃堆栈里出现
runtime.mapassign、runtime.mapdelete或hash_lookup，说明 map 已分配内存，问题出在并发访问 - 即使所有 goroutine 都只读（
v, ok := m[k]），只要有一个 goroutine 在写，就构成读写竞争 -
len(m)、for range m、delete(m, k)全部算作对 map 的访问，都需同步保护
sync.Map 不是万能解药，且不能掩盖未初始化问题
sync.Map 是并发安全的，但它本身也是值类型，必须正确初始化才能用。错误写法：
var sm sync.Map
sm.Store("key", "value") // ✅ 可以，sync.Map 的零值是可用的
但注意：sync.Map 的零值可用，不等于普通 map 可用；它只是内部用原子操作和分片规避了全局锁，并非“修复了 nil map”。如果你误把 sync.Map 当成普通 map 的替代而忽略其接口约束（比如键值必须是 interface{}），反而会引入类型转换开销或误用。
更现实的坑：
- 用
sync.Map替换普通map后，忘了改遍历方式：它没有原生range支持，Range是快照式回调，期间新写入不可见 - 高频写场景下，
sync.Map性能可能比sync.RWMutex + map差 2–5 倍 - 试图对
sync.Map做类型断言或反射操作，容易因底层结构变化出错
最易被忽略的初始化+并发组合陷阱
真正的高危模式，是“看似初始化了，实则没生效”的并发场景。例如：
- 在 goroutine 内部做
m := make(map[string]int，但该m是局部变量，外部无法访问 —— 外部仍用的是未初始化的包级变量 - 用
sync.Once延迟初始化全局map，但初始化函数里忘了加make()，只做了var m map[string]int - 测试时用单 goroutine 跑通，上线后多实例并发写同一 map，崩溃才暴露 —— 因为单例测试绕过了竞争窗口
这类问题不会在编译期报错，也不会在本地简单运行时复现，只有压测或线上流量突增时才突然崩，调试成本极高。
