Go map 并发读写为什么会崩：从 fatal error 到三种安全改法

Go 里很多人第一次遇到 map 并发问题，是在线上日志看到一句：fatal error: concurrent map writes。它不像普通 error 可以返回处理，而是直接让程序崩掉。更隐蔽的是，有些并发读写不会每次都崩，但已经存在 data race。

这篇文章按完整工作流回答一个 Go 问答题：为什么普通 map 不能随便被多个 goroutine 同时读写？怎么复现、怎么用 race 检测、最后该选 sync.RWMutex、sync.Map 还是 channel 收口？

目标和边界

本文讨论的是 Go 普通 map 在多 goroutine 场景下的读写安全问题。我们不展开 map 底层哈希桶细节，也不把主题扩展成完整并发模型教程。读完后，你应该能完成三件事：

1. 知道为什么并发写 map 会触发崩溃或 data race。
2. 能用 -race 找到共享 map 的访问路径。
3. 能按业务场景选择 RWMutex、sync.Map 或 channel 收口。

先说结论：普通 map 不是并发安全容器。只要有多个 goroutine 同时访问同一个 map，并且其中至少一个 goroutine 会写入，就应该加同步保护，或者改成更适合的并发访问模型。

全流程总览

排查 Go map 并发读写问题，可以按五步走：先确认报错现场，再用 race 检测辅助定位，随后找出共享 map，最后加锁保护并用测试验证。

阶段一：复现 fatal error 和 data race

目标

先让问题变得可观察。不要只说“偶尔崩”，要知道它是不是普通 map 的并发写入，还是业务逻辑里的其他异常。

关键动作

下面这段代码故意让多个 goroutine 写同一个 map。运行次数多了，很容易看到并发写 map 的崩溃。

package main

import (
    "fmt"
    "sync"
)

func main() {
    m := make(map[int]int)
    var wg sync.WaitGroup

    for i := 0; i 

如果程序没有马上崩，也不代表安全。可以打开 race 检测：

go run -race main.go
go test -race ./...

常用工具/代码选择

本地复现用 go run -race，项目验证用 go test -race ./...。线上服务不要临时用崩溃换证据，优先在测试环境用真实并发量复现。

检查点

你应该能拿到两类证据之一：崩溃日志里的 concurrent map writes，或者 race 检测报告里指出的读写位置。

阶段二：定位共享 map 的访问路径

目标

找到这张 map 被哪些 goroutine 访问，哪些路径读，哪些路径写。很多线上问题不是某个函数写错了，而是 map 被放到了全局缓存、服务结构体字段或闭包里，多处代码都能碰到它。

关键动作

按下面顺序查：

1. map 是全局变量、结构体字段，还是函数内部变量。
2. 写入点有哪些，例如赋值、删除、批量刷新。
3. 读取点有哪些，例如接口查询、定时任务、异步回调。
4. 这些访问是否可能同时发生。

type Cache struct {
    items map[string]string
}

func (c *Cache) Get(key string) string {
    return c.items[key]
}

func (c *Cache) Set(key, value string) {
    c.items[key] = value
}

上面这段看起来很普通，但只要 Get 和 Set 被不同 goroutine 同时调用，就存在风险。

常用工具/代码选择

可以用代码搜索先定位变量，再结合调用链看 goroutine 启动位置。对服务端项目来说，HTTP 请求并发、定时任务、消息消费都可能同时访问同一份内存。

检查点

如果你不能画出“哪个 goroutine 读、哪个 goroutine 写”的路径图，就先不要急着改方案。同步手段要保护的是访问边界，而不是某一行写入语句。

阶段三：选择 RWMutex、sync.Map 还是 channel 收口

Go 里解决共享 map 的常见做法有三类：用 RWMutex 包住普通 map、改用 sync.Map、把写入收口到一个 goroutine。它们不是谁比谁高级，而是适用场景不同。

方案一：普通热点读写，用 RWMutex

大多数业务缓存、连接状态、用户会话表，都可以先用 sync.RWMutex。它的优点是语义直接，普通 map 的写法也保留得比较完整。

type SafeCache struct {
    mu    sync.RWMutex
    items map[string]string
}

func NewSafeCache() *SafeCache {
    return &SafeCache{items: make(map[string]string)}
}

func (c *SafeCache) Get(key string) (string, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    v, ok := c.items[key]
    return v, ok
}

func (c *SafeCache) Set(key, value string) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.items[key] = value
}

方案二：只增缓存或读多写少，用 sync.Map

sync.Map 适合特定场景，例如 key 写入一次后多次读取，或者多个 goroutine 访问互不重叠的 key。它不是普通 map 的万能替代品。

var userCache sync.Map

func SaveUserName(id string, name string) {
    userCache.Store(id, name)
}

func LoadUserName(id string) (string, bool) {
    v, ok := userCache.Load(id)
    if !ok {
        return "", false
    }
    name, ok := v.(string)
    return name, ok
}

方案三：写入顺序很重要，用 channel 收口

如果业务要求所有写入按顺序处理，例如计数聚合、状态机推进、单房间游戏状态更新，可以让一个 goroutine 拥有 map，其他 goroutine 通过 channel 发送请求。

type update struct {
    key   string
    value int
}

func startOwner(in 

检查点

选择方案前先问三个问题：读写比例是多少？是否需要遍历和删除？是否要求写入按业务顺序发生？这三个答案比“哪个容器更快”更重要。

阶段四：压测和 race 检测一起验证

目标

修完以后，不能只靠肉眼看代码。并发问题要用 race 检测和并发压测一起验证。

关键动作

先跑单元测试和 race 检测，再构造并发请求打到相关接口。对于缓存类代码，建议补一个专门的并发测试。

func TestSafeCacheConcurrent(t *testing.T) {
    c := NewSafeCache()
    var wg sync.WaitGroup

    for i := 0; i 

go test -race ./...

检查点

验证通过的标准是：race 检测没有报告共享读写冲突，高并发请求结果稳定，代码审查能确认所有 map 访问都走同一个保护边界。

我的推荐流程

1. 先保留崩溃日志或 race 检测报告，不要凭感觉改。
2. 找出共享 map 的所有读写入口，尤其是全局变量和结构体字段。
3. 普通业务缓存优先用 RWMutex 封装，不把裸 map 暴露出去。
4. 只增少改、key 相对分散的缓存，再考虑 sync.Map。
5. 写入顺序很重要时，用 channel 让单个 goroutine 持有 map。
6. 补并发测试，跑 go test -race ./...，再做接口压测。

容易踩坑

落地速查表

总结一下，Go map 并发读写的根因是共享可变状态没有同步保护。别把它当成偶发小问题：先定位共享路径，再按业务场景选择同步方式，最后用 race 检测和压测验证，才是一条稳妥的修复路线。