go 的原生 map 非并发安全，多 goroutine 同时读写会触发致命错误（fatal error），且无法通过 recover 捕获；必须使用 sync.rwmutex、sync.map 或通道等机制显式同步访问。
go 的原生 map 非并发安全，多 goroutine 同时读写会触发致命错误（fatal error），且无法通过 recover 捕获；必须使用 sync.rwmutex、sync.map 或通道等机制显式同步访问。
在 Go 应用中，尤其是 HTTP 服务场景下，将共享状态（如 map[string]string）作为跨请求的数据存储是常见需求。但正如问题代码所示，仅对写操作做 goroutine 封装（如 worker 启动独立协程写入 map），而读操作（serveHandler 直接访问 *dataStore）完全裸露在 HTTP 处理协程中——这构成了典型的并发读写竞争（data race）。
Go 运行时对此类行为采取“零容忍”策略：一旦检测到同一 map 被多个 goroutine 同时读写（哪怕只是“一个写 + 一个读”），立即抛出 fatal error: concurrent map read and map write 并强制终止进程。该 panic 无法被 recover() 捕获，因为其本质不是用户层 panic，而是运行时层面的不可恢复崩溃，旨在防止内存损坏和未定义行为。
为什么简单加 goroutine 不能解决？
问题代码中 worker() 返回 *dataStore，serveHandler 直接解引用并遍历 map：
func serveHandler(store *dataStore) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
// ⚠️ 危险：此处无任何同步，直接读 map
data, _ := json.Marshal(*store)
w.Write(data)
}
}
而 worker 内部的匿名 goroutine 又在持续写入：
go func() {
for data := range stream {
(*store)[key] = value // ⚠️ 危险：无锁写入
}
}()
两个或更多 goroutine（HTTP handler + worker）在无协调下访问同一底层哈希表，race detector 会明确报出类似：
WARNING: DATA RACE Read at 0x... by goroutine 10: main.serveHandler.func1(...) Write at 0x... by goroutine 7: main.worker.func1(...)
正确解决方案：优先使用 sync.RWMutex
RWMutex 是最直观、可控性最强的方式——允许多个 reader 并发读，但 writer 独占写，完美匹配“高频读 + 低频写”的典型 Web 场景：
DataStore
| 方案 | 适用场景 | 注意事项 |
|---|---|---|
sync.Map |
键值对数量大、读远多于写、且无需遍历全量数据 | 不支持 range，无 len()，API 较重，GC 压力略高；适合缓存类场景 |
| 通道（Channel）封装 | 逻辑天然事件驱动、需严格串行化访问 | 性能开销较大，易阻塞，不适合高频读（如每秒数百次 GET） |
sync.Mutex |
简单场景，读写频率接近 | 读操作无法并发，吞吐低于 RWMutex
|
总结
Go 的 map 并发不安全不是 bug，而是设计取舍：以零成本读写换取极致性能，将同步责任明确交予开发者。永远不要假设“目前没崩就代表安全”——数据竞争具有随机性和环境依赖性，可能在压测、高负载或不同 CPU 架构下才暴露。务必：
1️⃣ 对所有共享 map 的读写操作施加同步原语；
2️⃣ 本地开发阶段始终启用 -race 编译；
3️⃣ 在生产部署前，通过 go test -race ./... 全面扫描；
4️⃣ 优先选用 sync.RWMutex 封装，兼顾安全性与性能。
