直接回答：Go map 不是并发安全的，运行时对并发写做了检测（发现哈希表正在被修改）直接 fatal error: concurrent map writes——这是不可恢复的致命错误而非可捕获的 panic。设计上故意如此：为普通场景省掉锁开销。并发场景的两种正解：sync.RWMutex 保护的普通 map，读多写少时读锁不互斥、性能可控；sync.Map 适合两个特定场景——键集合相对固定（读远多于写）、或不同 goroutine 操作不相交键集合。
展开解析：sync.Map 内部是 read/dirty 双 map 加 miss 计数的渐进式同步，读命中 read 时无锁。但 Load 未命中、Store 新键、Range 都会加锁，写多读少或频繁 Range 的场景性能反而不如 RWMutex+map。选型清单：通用共享缓存→RWMutex+map（API 直观、可 Range、能一次复合操作）；键集合稳定读极多写极少→sync.Map；分片要求极致→分片锁（sharded map，每片一把锁）。注意 RWMutex 的读锁也不能在持锁期间写；sync.Map 的 Range 是快照语义且顺序随机。压测数据说话：读多写少场景 sync.Map 读路径可快数倍，写均衡场景分片锁通常最优。
追问方向：concurrent map read and write 检测基于什么标记？RWMutex 的写饥饿如何避免？分片锁如何决定分片数？
（约 440 字）