Go原生map非线程安全是设计取舍，runtime检测并发读写即panic以避免数据损坏；sync.RWMutex封装最常用，sync.Map仅适用于特定场景，分片锁需谨慎引入。
Go 的原生 map 不是线程安全的，这不是 bug，而是设计取舍：runtime 主动在检测到并发读写时 panic（如 fatal error: concurrent map read and map write），防止数据损坏。直接用它跑多协程读写，压测或高负载下必崩。
为什么 runtime 会 panic 而不是静默出错
Go 的 map 底层是哈希表，涉及动态扩容、桶迁移、键重散列等非原子操作。多个 goroutine 同时触发这些内部状态变更，会导致内存越界、指针悬空或无限循环——panic 是 runtime 的“急刹车”，避免更难排查的未定义行为。
- 哪怕只是两个 goroutine 同时写不同
key，也可能因扩容竞争而 panic -
range遍历本质是读操作，但若遍历时有 goroutine 正在写，同样触发 panic - 仅并发读（全程无写）是安全的；但只要混入一次写，所有读都必须同步
sync.RWMutex 封装原生 map 是最可控方案
90% 的业务场景下，显式加锁比依赖 sync.Map 更清晰、性能更可预测。关键是别锁整个 map 做无谓串行化。
- 用
sync.RWMutex而非sync.Mutex：读多时允许多个 goroutine 并发读，只在写时阻塞 - 封装成结构体，把
map和RWMutex绑定，避免锁对象暴露 -
Get方法必须用RLock()+defer RUnlock()，别漏掉defer -
Range遍历前先RLock()，遍历完立刻RUnlock()，不能把锁持有到循环体外
sync.Map 不是“线程安全 map”的通用替代品
sync.Map 是为特定场景优化的妥协方案，不是原生 map 的并发安全平替。误用反而引入新问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不支持
len()，必须用Range()手动计数，开销大且非原子 -
Load()返回(value, bool)，忽略bool直接用value会拿到零值，误判存在性 -
Range()是快照式回调，遍历时其他 goroutine 仍可增删改，结果不一致是正常设计 - 频繁写同一 key 或大量短生命周期 key（如请求 ID）会让
readmap 快速失效，性能断崖下跌
分片锁（sharded map）只在明确瓶颈时才值得引入
单个 RWMutex 成为写吞吐瓶颈（比如 QPS 上万、写入密集、key 分布离散）时，才考虑分片。过早优化得不偿失。
- 按 key 哈希取模分 N 个子 map，每个配独立
RWMutex - 写操作只锁对应分片，读操作也只锁对应分片
- 分片数不宜过多（如 32 或 64），否则内存和调度开销上升
- 无法原子操作跨分片的逻辑（如“全量清空”或“统计总数”），需额外协调
真正容易被忽略的是：对 map[string]*User 这类结构，从 map 中读出指针本身是安全的，但并发修改 *User 字段仍是独立的数据竞争问题——这和 map 安全性无关，得用另一把锁或原子操作管住。
