Go map并发写会panic，因扩容涉及桶复制与指针重连，运行时通过hashWriting标志位检测并发并主动崩溃；sync.Map无扩容机制但写性能差，预分配容量+sync.RWMutex最可控。
map 扩容时为什么并发写会 panic
go 运行时在 hashmap.go 里对写操作加了 hashwriting 标志位，只要检测到另一个 goroutine 正在读或写（哪怕只是 m[key] 读取），就直接触发 fatal error: concurrent map writes。这不是竞态“可能出错”，而是设计上「宁可崩溃也不让数据错乱」——扩容涉及桶数组复制、指针重连、旧桶逐步迁移，此时若并发访问，bucket 链表可能断裂、tophash 与 key 错位、甚至访问野指针。
sync.Map 不能解决扩容冲突？它压根不扩容
sync.Map 的底层不是单个哈希表，而是分片（shard）+ 只读映射 + 延迟初始化的组合。它没有传统 map 的「桶数组扩容」机制：每个 shard 是独立的 map[interface{}]interface{}，写入时只在当前 shard 内部操作；读取先查只读快照，miss 后再加锁查 dirty map。所以它规避了「扩容中被读」的问题，但代价是：
- 写性能比加锁的普通 map 差 2–5 倍（尤其写多时要频繁升级只读映射）
-
Range是快照语义，遍历时新增的 key 不可见 - 没有
Clear方法，也不能用make预分配容量
用 sync.RWMutex + 预分配 map 是最可控的方案
真正控制扩容时机、避免运行时扩容干扰并发的唯一办法，是让 map 在高并发前就完成扩容。关键点：
- 用
make(map[K]V, n)显式预估容量，比如已知要存 10 万条，就make(map[string]*User, 131072)（选 2 的幂次，避免中间多次扩容） - 写操作必须包住整个逻辑：从判断是否存在、到赋值、再到可能的 delete，全在
mu.Lock()内 - 读操作用
RUnlock必须 defer，且绝不在Range回调里调用任何写方法（否则死锁） - 如果写非常密集（如每秒数万次），考虑按 key 分片（比如
shards[hash(key)%N]），把锁粒度降到单个分片
Go 1.24+ 的 Swiss Tables 对并发没帮助
虽然 Go 1.24 把 map 底层换成了 Swiss Tables（用 control byte 替代 tophash），但「高位粗筛 + 低位寻址」的哈希拆分逻辑没变，更关键的是：它依然没有并发安全机制。runtime 层的 hashwriting 检测逻辑照常工作，sync.Map 也没因此改写实现。所有关于「新底层自动支持并发」的说法都是误读——Swiss Tables 解决的是单线程下的缓存局部性与查找速度，不是并发模型。
