Go map并发读写会触发fatal error而非panic，因运行时强制保护：只要两个goroutine同时写或一读一写，立即crash；sync.Map并非万能替代，仅适用于读多写少、键稳定的场景，且不支持for range、无len()、内存开销大。
为什么全局变量一并发就读写 panic
Go 运行时对 map 的并发读写有硬性保护：只要两个 goroutine 同时执行 m[key] = value 或一个在 range m、另一个在 delete(m, key)，就会立即触发 fatal error: concurrent map writes 或 concurrent map read and map write。这不是警告，是直接 crash —— 它不给你重试机会，也不等你压测才发现。
- 常见误判：以为“只读安全”就等于“读 + 读安全”，其实没问题；但只要混入任意一个写操作（哪怕只是
m["x"]++），所有读都必须同步 - 典型场景：HTTP handler 中直接操作全局
var users map[string]*User，每个请求开 goroutine 写入或遍历 - 陷阱点：struct 字段里嵌了
map或[]byte，你以为传的是副本，其实底层数据仍共享——这会让锁失效
sync.RWMutex 用错位置照样 panic
sync.RWMutex 不是插上就能用的魔法开关，锁的粒度和覆盖范围错了，照样读到脏数据或死锁。
- 锁变量必须和被保护的数据绑定在同一作用域：全局 map 配全局
var mu sync.RWMutex；结构体字段的 map 就该用结构体里的mu sync.RWMutex字段，不能在函数里 new 一把临时锁 - 读操作必须用
Rlock()+RUnlock()，不是Lock()；写操作必须用Lock()+Unlock()；混用会导致读阻塞写，甚至死锁 - 别在锁里调
http.Get或time.Sleep—— 一个 goroutine 卡住，其他所有读写全排队 - range map 前必须先
mu.RLock()，且整个 range 循环必须在mu.RUnlock()之前结束；中途 break 或 return 忘 defer，就会永久持锁
sync.Map 真的能替代原生 map 吗
sync.Map 是为高频写 + 简单键值设计的，但它不是原生 map 的无缝替换，类型和行为差异会咬人。
- 不支持
for range：必须用m.Range(func(key, value interface{}) bool { ... })，回调里不能直接 return，得靠返回false提前退出 - 类型擦除：存进去的是
interface{}，取出来要自己断言，比如v, ok := val.(string)，断言失败不报错，而是ok == false - 内存开销大：每个 entry 单独分配堆内存，小对象场景下比加锁的原生 map 多 2–3 倍内存占用
- 读性能略低：内部用了 read/write 分离 + atomic 操作，单次读比原生 map 慢 10%–20%，但并发读多时整体吞吐更高
深拷贝字段才能真正隔离修改
结构体里含 map、slice、chan 或指针字段时，赋值或传参后看似“新变量”，实际仍共享底层数据——这时加锁也拦不住意外修改。
立即学习“go语言免费学习笔记（深入）”；
- 切片复制不能只用
append(dst[:0], src...)：如果src底层数组没扩容，dst和src仍共用同一块内存 - 可靠一维切片拷贝：用
copy(dst, src)，前提是dst已预分配足够容量 - 嵌套结构深拷贝：用
json.Marshal+json.Unmarshal最稳妥，但注意字段需导出（首字母大写）、不能含func或unsafe.Pointer - 想零拷贝？只能手动递归复制每个指针字段，或用
encoding/gob（支持私有字段，但更慢）
真正麻烦的从来不是“要不要加锁”，而是“锁什么、怎么复制、谁在共享那块内存”。很多 panic 发生前，变量早就被悄悄改过三次了。
