go 1.8 引入了更严格的运行时检测机制，当同一 map 同时被多个 goroutine 迭代（range）和写入（如赋值、delete）时，会立即触发 fatal error：“concurrent map iteration and map write”。
go 1.8 引入了更严格的运行时检测机制，当同一 map 同时被多个 goroutine 迭代（range）和写入（如赋值、delete）时，会立即触发 fatal error：“concurrent map iteration and map write”。
该错误并非源于函数内部逻辑缺陷，而是调用上下文存在并发竞争：Set 函数被多个 goroutine 同时调用，且传入的 store（或 firstSet）是共享的可变 map。Go 1.8 及之后版本强化了对 map 并发访问的运行时检查——即使只是“一个 goroutine 在 range，另一个在写”，也会 panic（此前版本可能静默崩溃或产生数据竞争）。
? 根本原因分析
-
for dmn, parsed := range store是迭代操作（读）； - 若其他 goroutine 此时向
store执行store[key] = value或delete(store, key)，即构成并发读-写； - Go 运行时在 1.8+ 中主动捕获并中止程序，而非依赖竞态检测器（
-race）。
✅ 正确解决方案：加锁保护共享 map
推荐使用 sync.RWMutex（读写互斥锁），兼顾性能与安全性：
import "sync"
var storeMutex sync.RWMutex
var store = make(map[string]*Parsed)
// 安全读取 store（允许多个 goroutine 并发读）
func getStore() map[string]*Parsed {
storeMutex.RLock()
defer storeMutex.RUnlock()
// 注意：返回副本或只读视图更安全；若需返回引用，请确保调用方不修改
m := make(map[string]*Parsed, len(store))
for k, v := range store {
m[k] = v
}
return m
}
// 安全写入 store
func updateStore(key string, val *Parsed) {
storeMutex.Lock()
defer storeMutex.Unlock()
store[key] = val
}
然后重构 Set 函数，避免直接暴露原始 map：
func Set(firstSet map[string][]App, store map[string]*Parsed) map[string]map[string]struct{} {
s := make(map[string]map[string]struct{})
// 安全遍历 store —— 使用只读副本
for dmn, parsed := range store {
for cId := range firstSet { // 注意：此处仅需 key，无需 apps 值
if s[dmn] == nil {
s[dmn] = make(map[string]struct{})
}
s[dmn][cId] = struct{}{}
}
}
return s
}
⚠️ 关键注意事项：
- ❌ 不要将原始 map（如
store）直接作为参数传入并发调用的函数——除非你 100% 确保它在整个生命周期内只读； - ✅ 更佳实践：封装 map 访问为方法，内部统一加锁（如
Store.Get(),Store.Set()）； - ✅ 若
firstSet也由多 goroutine 写入，则同样需加锁或改用sync.Map（但注意：sync.Map适用于低频写、高频读场景，且不支持range，需用Load/Range方法）； - ✅ 始终启用
-race构建检测潜在数据竞争：go run -race main.go。
? 总结
Go 的 map 本身不是并发安全的，这是语言设计的明确约定。Go 1.8 的 panic 是一种“fail-fast”机制，帮助开发者尽早发现并发 bug。解决之道不是规避错误，而是通过同步原语（sync.Mutex/sync.RWMutex）或线程安全替代品（如 sync.Map）显式管理共享状态。切勿依赖“暂时没 panic”来判断代码正确性。
