Go 里直接并发读写 map 会 panic
不是警告，是 runtime 直接崩溃，错误信息固定为：fatal error: concurrent map read and map write。Go 的原生 map 不是线程安全的，哪怕只是“多个 goroutine 同时读”，只要其中有一个在写，就可能触发这个 panic —— 因为底层 hash 表扩容时会重排 bucket，读操作可能访问到半更新状态的内存。
常见错误场景包括：HTTP handler 共享一个全局 map 缓存、worker goroutine 持续更新配置映射、测试中用 go func() { m[k] = v }() 并发赋值。
- 别指望“只读不写”就安全：只要 map 在其他 goroutine 中被修改过（哪怕是一次），并发读就不可靠
-
sync.Map是唯一标准库提供的并发安全替代，但它不是万能解药——它针对的是「读多写少」场景，写性能比加锁map差不少 - 如果写操作频繁（比如每秒几百次以上），用
sync.RWMutex包一层普通map反而更稳、更可预测
什么时候该用 sync.Map，而不是 sync.RWMutex + map
sync.Map 的设计目标很明确：降低高并发读场景下的锁争用。它把数据分片 + 延迟初始化 + 读写分离存储，让读几乎不加锁；但代价是写路径更长、内存占用更高、不支持遍历（Range 是快照，不保证一致性）。
典型适用场景：cache 类结构（如请求 ID → 处理状态）、服务发现中节点注册/心跳更新（写少，查多）、metrics 标签聚合（key 动态增长，但单 key 更新不频繁）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果你需要
len(m)、for range m或者强一致性迭代，别用sync.Map，它不支持 -
sync.Map.LoadOrStore看似原子，但注意：如果 key 不存在，它会执行一次写入并返回 false；如果存在，则只读取并返回 true —— 这个“判断+写入”不是真正意义上的 CAS，无法替代atomic.CompareAndSwap语义 - 它的零值可用，不用显式
new(sync.Map)，但内部字段不可导出，无法反射或 deep-copy
sync.Map 的 Load/Store 不保证跨 key 的操作顺序
这是最容易被忽略的可见性盲区：A goroutine 执行 m.Store("a", 1); m.Store("b", 2)，B goroutine 调用 m.Load("b") 得到 2，不代表它一定能立刻看到 "a" 是 1 —— sync.Map 对不同 key 的操作不提供 happens-before 保证。
换句话说，它不解决“多个相关状态之间的一致性”问题。比如你用两个 key 分别存用户余额和冻结金额，就不能靠 sync.Map 保证二者读取时的相对新鲜度。
- 需要跨 key 强一致？必须引入额外同步机制，比如用同一个
sync.Mutex锁住整个结构体，或用chan串行化更新 -
sync.Map的Range回调函数内，对 map 的任何修改（Store/Delete）都无效，且不会报错，只会静默失败 - 它没有类似
atomic.Value那样的“写后立即对所有 goroutine 可见”的内存屏障语义，底层依赖的是 Go runtime 的 memory model，但粒度仅限于单 key
Lock-free 在 Go 里基本没你想象的用武之地
Go 的调度器和内存模型决定了：真正在用户代码层实现无锁（lock-free）数据结构，既难写又难测，还容易因 GC 或编译器优化引入隐蔽 bug。标准库中只有 atomic.Value 和部分 sync/atomic 操作是 lock-free 的，其余全是基于 mutex 或 channel 的协作式同步。
所谓 “Go 的 lock-free 数据结构”，99% 是营销话术。第三方包如 concurrent-map 或 go-datastructures 里的实现，底层仍是 sync.RWMutex 分片，只是把锁粒度变细了，不是真正无锁。
- 别为了“lock-free”而放弃可维护性：一个清晰的
sync.RWMutex+ 普通map，比一堆atomic.LoadUint64+unsafe.Pointer转换更容易 debug - Go 的
atomic包只对基础类型（int32/int64/uintptr/unsafe.Pointer）提供 lock-free 操作，对结构体或 map 这种复合类型，必须靠锁或atomic.Value封装指针 - 真正需要极致性能的场景（如高频 ticker 更新指标），优先考虑 ring buffer、pre-allocated slice + atomic index，而不是硬啃 lock-free map
