Go原生map一并发就崩溃，因其底层哈希表扩容迁移时修改指针和元数据，另一goroutine执行m[k]、len(m)或range会访问中间态内存，触发fatal error；sync.Map仅适用于低写高读场景，不支持len、range等原生操作。
Go原生map为什么一并发就崩溃
因为底层哈希表在扩容、迁移桶时会修改内部指针和元数据，此时若另一个goroutine正在执行m[k]、len(m)或range m，就会访问到中间态内存——这不是“偶尔出错”，而是未定义行为，直接触发fatal error: concurrent map read and map write或fatal error: concurrent map writes。
常见误区是认为“只读操作安全”，但事实是：只要map存在任何写操作（哪怕只是m[k] = v），所有其他goroutine的任何访问（包括len(m)）都必须同步。没有例外。
- panic不是随机发生，而是在竞争条件被运行时检测器捕获时立即终止进程
- 即使
GOMAXPROCS=1，也不能避免数据竞争——goroutine调度仍可能在指令边界切换，破坏map内部状态一致性 - map中存的是
*User，并发改(*User).Name不会引发map panic，但这是另一层并发问题，需单独同步
sync.Map不是万能替代品
sync.Map设计目标很明确：适用于**低写高读**场景，比如配置缓存、连接池元信息等；它用读写分离+原子操作+延迟提升dirty map来减少锁争用，但代价是接口不兼容原生map，且写多时性能反而更差。
它的API是函数式调用：Store、Load、Delete、Range，不能用m[k]语法，也不能直接遍历或取长度。
立即学习“go语言免费学习笔记（深入）”；
-
Load先无锁查read，未命中再加锁查dirty，所以高频写会导致misses累积，触发dirty→read提升，带来额外开销 -
Range回调返回的是快照，期间新写入不可见；且无法中断遍历（返回false仅停止后续迭代，不回滚已执行部分） - 值类型必须是
interface{}，无法做类型推导，频繁装箱拆箱影响GC压力
什么时候该用sync.RWMutex而不是sync.Map
当你的使用模式是“读多写少但写操作较重”（如批量更新、结构体字段赋值、嵌套map操作），或者需要支持len()、delete()、for range等原生语法时，sync.RWMutex比sync.Map更可控、更易测试。
典型做法是把map和锁封装成结构体：
type SafeMap struct {
mu sync.RWMutex
m map[string]int
}
func (s *SafeMap) Get(k string) (int, bool) {
s.mu.RLock()
defer s.mu.RUnlock()
v, ok := s.m[k]
return v, ok
}
func (s *SafeMap) Set(k string, v int) {
s.mu.Lock()
defer s.mu.Unlock()
s.m[k] = v
}
- 读操作用
RUnlock，允许多个goroutine并发读，写操作独占Lock - 初始化时必须在锁保护下完成：
s.m = make(map[string]int)，否则make本身也可能被并发干扰 - 避免在锁内做耗时操作（如HTTP调用、文件IO），否则会阻塞所有读写
最容易被忽略的并发陷阱
不是没加锁，而是锁的粒度或范围不对——比如在map外层加了锁，但对map中存储的指针所指向的对象又做了并发修改，却忘了同步那部分。
例如：m["user"] = &User{Name: "A"}，之后多个goroutine执行m["user"].Name = "B"，这不会触发map panic，但User.Name字段本身是竞争的。
- map安全 ≠ 值安全：
sync.Map或sync.RWMutex只保护map结构体自身，不保护其value指向的内存 - 如果value是struct指针，字段修改需额外同步（如字段级
sync.Mutex、atomic、或channel协调） - 切忌用
defer mu.Unlock()后还继续用map——defer只在函数return时执行，中间代码仍处于临界区
