Go map concurrent 并发读写为什么会 fatal error

如果 Go 程序报出 fatal error: concurrent map read and map write 或 fatal error: concurrent map writes，先不要给 map 扩容或改 key。根因通常是多个 goroutine 在没有同步的情况下共享普通 map，至少一条路径正在写入；range、delete、clear 也要算进访问边界。只读共享可以成立，但只要运行期间存在写入，就必须把读写纳入同一套同步方案。

这条 fatal error 到底说明了什么

普通 map 不是并发容器。一个 goroutine 执行 m[key] = value 时，另一个 goroutine 同时查找或遍历同一个 map，运行时可能直接终止进程；两个写入方也可能触发 concurrent map writes。错误信息很醒目，但它只告诉你访问重叠了，并不会指出业务上的共享关系。

排查时先画出“谁持有 map、谁能改变 map”。除了赋值，还要搜索 delete(m, key)、clear(m) 和 for k, v := range m。如果 map 被放进全局变量、结构体字段或闭包，尤其要检查启动 goroutine 的地方。不要用“这次读得很快”推断安全；并发正确性依赖同步关系，不依赖时序运气。

先把所有访问收进同一把锁

对多数业务缓存、配置表和小型索引，普通 map 配合 sync.RWMutex 最容易读懂。关键不是“加一把锁”四个字，而是所有访问都经过封装方法，读锁和写锁覆盖完整的 map 操作。

import "sync"

type Registry struct {
	mu sync.RWMutex
	data map[string]string
}

func (r *Registry) Get(name string) (string, bool) {
	r.mu.RLock()
	defer r.mu.RUnlock() // 读路径只保护查找，返回值先复制出来
	v, ok := r.data[name]
	return v, ok
}

func (r *Registry) Put(name, addr string) {
	r.mu.Lock()
	defer r.mu.Unlock() // 写路径覆盖赋值，避免与查找或遍历重叠
	r.data[name] = addr
}

如果要返回切片、指针或嵌套 map，锁释放后仍可能引用内部可变数据，这时要复制结果或把后续修改也纳入锁。遍历时保持读锁直到遍历完成，不能只在取长度时加锁。

sync.RWMutex、sync.Map 和 channel 怎么选

这三个方案解决的是不同的访问模型。先看约束，再选容器：

sync.Map 不是“普通 map 加速版”，也不适合把复杂的多字段事务硬塞进一连串 Load、Store。需要“读取旧值、判断、更新多个字段”时，带锁的普通 map 通常更清晰。若状态天然由一个事件循环维护，channel 所有权能让写入集中，但要把关闭和超时一起设计。

修复后用 race detector 复查真实路径

先在测试和集成场景运行：

# 用竞态检测器执行整个包的测试，覆盖真实并发入口
go test -race ./...

# 也可以直接运行带并发压测路径的程序
go run -race ./cmd/server

竞态检测器只能发现实际运行到的冲突，因此测试要同时触发读取、写入、删除和遍历，不能只测单 goroutine 的 happy path。看到 WARNING: DATA RACE 时，沿着报告里的两个访问栈回到同一个 map；加锁后仍报错，常见原因是还有别的别名、返回了内部可变对象，或锁没有覆盖整个复合操作。

最后做一次检查：普通 map 是否只有只读共享；所有写入是否通过同一个 owner；锁是否覆盖 range 和复合更新；go test -race 是否跑到了生产式并发。四项都能回答清楚，fatal error 才算真正处理完。

常见问题

多个 goroutine 同时读普通 map 安全吗？

在 map 生命周期内确实没有任何写入或结构变化时，只读共享通常可以；一旦有写入、删除、清理或遍历与写入重叠，就不能继续按只读处理。

加了读锁还会出现 concurrent map writes 吗？

会，如果写路径使用了读锁、绕过封装直接访问字段，或某个别名仍在无锁修改。所有修改必须走写锁，且同一个 map 不能存在未纳入约束的入口。

sync.Map 能彻底避免 fatal error 吗？

它为并发访问提供了专门语义，但不能替你保护 map 中保存的可变对象，也不能自动保证多次操作组成的业务事务一致。选择前先确认数据模型。