Go的map并发读写会panic，因运行时检测到并发写或读写竞争时触发fatal error；其扩容非原子且无内置锁，仅并发读虽不panic但可能导致数据不一致。
为什么 Go 的 map 在并发读写时会 panic
Go 运行时会在检测到多个 goroutine 同时对同一个 map 做写操作（或读+写）时，直接触发 fatal error: concurrent map writes；如果只是并发读，不会 panic，但可能读到未完成写入的中间状态（如部分字段更新、指针悬空），导致数据不一致或崩溃。这不是“概率性 bug”，而是运行时强制检查的确定性失败——map 内部没有内置锁，且其扩容过程涉及桶数组复制、键值迁移等非原子操作。
哪些场景下看似安全实则危险
常见误判包括：
- 只读 map 但底层被其他 goroutine 修改过（比如初始化后没冻结，后续又被写入）
- 用
sync.Map却仍手动加锁或重复包装（sync.Map自身已做分段锁优化，额外锁反而降低性能） - 在
for range遍历map时，另一个 goroutine 调用delete或赋值 —— 此时遍历行为未定义，可能 panic 或漏遍历 - 把 map 作为结构体字段嵌入，并认为 “结构体加了互斥锁，map 就安全” —— 错，锁必须覆盖所有访问路径，且不能在锁外取 map 的引用并传递出去
sync.Map 的适用边界和坑点
sync.Map 是为“读多写少”场景设计的，它用空间换时间：读操作无锁，写操作按 key 哈希分片加锁。但它不支持遍历一致性快照，也不支持获取长度（Len() 方法是 O(n) 且非原子）。实际使用要注意：
- 不要用
sync.Map存储需要频繁迭代的集合，比如缓存淘汰、批量清理 -
LoadOrStore和Range不是事务性的：Range回调中修改 map 可能导致 panic 或无限循环 - 值类型如果是指针或 struct，需自行保证其内部字段的线程安全（
sync.Map只保护 map 本身，不递归保护 value） - 初始化后尽量避免混用原生
map操作（如m[key] = val），应统一走sync.Map方法
var m sync.Map
m.Store("a", 1)
m.Load("a") // 返回 value, true
m.Range(func(key, value interface{}) bool {
fmt.Println(key, value)
return true // 必须返回 true 继续，false 中断
})
更可控的替代方案：读写锁 + 原生 map
当业务需要强一致性、支持遍历、或写操作并不稀疏时，sync.RWMutex 包裹原生 map 往往比 sync.Map 更清晰、更易测试：
- 读操作用
RLock()/RUnlock()，写操作用Lock()/Unlock() - 可轻松实现带条件的批量操作（如“遍历删除所有过期项”）
- 避免
sync.Map的类型擦除开销（interface{} 拆装）和不可预测的 GC 压力 - 注意：不能在持有
RWMutex期间调用可能阻塞或回调用户代码的函数（比如 HTTP 请求、channel 发送），否则可能死锁
type SafeMap struct {
mu sync.RWMutex
m map[string]int
}
func (sm *SafeMap) Get(key string) (int, bool) {
sm.mu.RLock()
defer sm.mu.RUnlock()
v, ok := sm.m[key]
return v, ok
}
func (sm *SafeMap) Set(key string, v int) {
sm.mu.Lock()
defer sm.mu.Unlock()
sm.m[key] = v
}
真正容易被忽略的是：**map 安全与否，不取决于“有没有 goroutine”，而取决于“有没有共享可变状态 + 缺乏同步机制”**。哪怕只开两个 goroutine，只要一个写、一个读，就已越界。别依赖“好像没出错”来判断正确性。 
