Go内置map非并发安全，多goroutine读写会触发panic；应依场景选sync.Mutex、sync.RWMutex或sync.Map，推荐用RWMutex封装安全计数器。
为什么直接在 goroutine 里读写 map 会 panic
Go 的内置 map 不是并发安全的。只要有两个 goroutine 同时对同一个 map 执行写操作（m[key] = value），或一个写、一个读（range m 或 v, ok := m[key]），运行时大概率触发 fatal error: concurrent map writes 或 concurrent map read and map write。这不是概率问题，而是 Go 运行时主动检测并中止程序，防止数据损坏。
常见误用场景包括：启动多个 goroutine 处理日志行、HTTP 请求或消息队列项，并把结果累加进同一个全局 map[string]int；或者用 sync.WaitGroup 等待所有 goroutine 完成后才读取 map —— 这不能避免中间过程的竞态。
三种安全方案对比：sync.Mutex vs sync.RWMutex vs sync.Map
选择取决于读写比例、键数量、是否需要遍历等实际需求：
-
高频写 + 偶尔读：用
sync.Mutex最简单直接，开销小，适合键数不多、写操作占主导的统计场景（如实时错误码计数） -
高读低写：优先选
sync.RWMutex，允许多个 goroutine 并发读，写时独占，比 Mutex 更高效 -
大量键 + 读多写少 + 不需遍历：考虑
sync.Map，它内部做了分片和延迟初始化，避免全局锁，但不支持range，遍历时必须用Range()回调，且值类型只能是 interface{}，需类型断言
注意：sync.Map 不是万能替代品。如果需要原子性地「检查并设置」（check-then-set）、或频繁遍历所有键值对，sync.Map 反而更麻烦，此时 sync.RWMutex + 普通 map 更清晰可靠。
立即学习“go语言免费学习笔记（深入）”；
用 sync.RWMutex 实现安全的并发计数器
这是最常用、可读性好、扩展性强的做法。核心是把 map 和锁封装成结构体，暴露线程安全的方法：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
type Counter struct {
mu sync.RWMutex
data map[string]int64
}
func NewCounter() *Counter {
return &Counter{
data: make(map[string]int64),
}
}
func (c *Counter) Inc(key string) {
c.mu.Lock()
c.data[key]++
c.mu.Unlock()
}
func (c *Counter) Get(key string) int64 {
c.mu.RLock()
defer c.mu.RUnlock()
return c.data[key]
}
func (c *Counter) GetAll() map[string]int64 {
c.mu.RLock()
defer c.mu.RUnlock()
// 浅拷贝，避免外部修改原始 map
result := make(map[string]int64, len(c.data))
for k, v := range c.data {
result[k] = v
}
return result
}
使用示例：
counter := NewCounter()
var wg sync.WaitGroup
for i := 0; i < 100; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
counter.Inc("request")
if i%10 == 0 {
counter.Inc("slow_request")
}
}(i)
}
wg.Wait()
fmt.Println(counter.GetAll()) // map[request:100 slow_request:10]
关键点：GetAll() 必须拷贝 map 内容再返回，否则外部拿到的是内部 map 的引用，后续并发写会导致 panic；Inc() 用 Lock() 而非 RWMutex 的 RLock()，因为是写操作。
sync.Map 的典型误用与正确姿势
很多人以为 sync.Map 可以无脑替换普通 map，结果发现 range 报错、类型断言失败、甚至漏掉某些 key。根本原因是它的 API 设计哲学不同：
-
sync.Map不提供len()或直接遍历能力，必须用Range(f func(key, value interface{}) bool) -
LoadOrStore(key, value)返回的是(actualValue, loaded bool)，不是简单赋值 - 所有 key/value 都是
interface{}，存数字时别忘了转成int64，取出来要显式断言
正确用法示例（统计字符串出现次数）：
var sm sync.Map
// 并发写入
for i := 0; i < 50; i++ {
go func(s string) {
v, _ := sm.LoadOrStore(s, int64(0))
count := v.(int64)
sm.Store(s, count+1)
}("item")
}
// 遍历结果
var result map[string]int64 = make(map[string]int64)
sm.Range(func(key, value interface{}) bool {
k := key.(string)
v := value.(int64)
result[k] = v
return true // 继续遍历
})
fmt.Println(result)
注意：上面的 LoadOrStore + Store 组合不是原子的，两个 goroutine 可能同时读到 0，然后都存 1，导致计数丢失。真要原子增，得用 CompareAndSwap 或回退到 mutex 方案。
真正需要小心的是：一旦用了 sync.Map，就别想着把它当普通 map 用；而用 sync.RWMutex 封装普通 map 时，最容易被忽略的是「返回 map 前必须深拷贝内容」——这个动作看似多余，实则是并发安全的最后一道防线。
