go 语言中的 map 默认不是线程安全的，多个 goroutine 同时读写同一 map 会触发数据竞争，导致程序崩溃或未定义行为；即使只读取指针并修改其指向的结构体，若 map 本身被并发修改，仍存在严重风险。
go 语言中的 map 默认不是线程安全的，多个 goroutine 同时读写同一 map 会触发数据竞争，导致程序崩溃或未定义行为；即使只读取指针并修改其指向的结构体，若 map 本身被并发修改，仍存在严重风险。
在 Go 中，map 类型（如 map[int]*User）本身不具备并发安全保证。这意味着：只要存在任意 goroutine 对该 map 执行写操作（如 m[key] = value、delete(m, key)、m[key]++），而其他 goroutine 同时进行读或写操作（包括 len(m)、for range m、_, ok := m[key]），就会构成数据竞争（data race）——这是 Go 中明确禁止的未定义行为，可能导致 panic、内存损坏、静默数据错误，甚至程序崩溃。
值得注意的是，线程不安全的边界仅限于 map 的底层哈希表结构操作，而非其值类型的内容。例如：
var m = make(map[int]*User)
// goroutine A:
m[1] = &User{Name: "Alice"} // ✅ 写 map（危险，若其他 goroutine 同时读/写）
// goroutine B:
u := m[1] // ✅ 读 map（安全？仅当无并发写！）
u.Name = "Bob" // ✅ 修改 *User 字段（与 map 无关，但需确保 u 不被其他 goroutine 同时修改）上述代码中：
- u := m[1] 是对 map 的读操作，若此时无其他 goroutine 修改 m，该操作本身是安全的；
- u.Name = "Bob" 修改的是 *User 指向的结构体字段，不涉及 map 结构变更，因此该操作的线程安全性完全取决于 *User 是否被多 goroutine 并发修改——这与 map 无关，属于常规结构体并发访问问题；
- 但一旦 goroutine A 和 goroutine B 同时运行且无同步机制，则 m[1] = ... 与 m[1] 就构成 map 级别的竞态，Go 运行时可能立即 panic（自 Go 1.6 起，运行时会主动检测并中止），或在极端情况下引发内存布局错乱。
⚠️ 特别提醒：
- len(m)、for range m、key, ok := m[k] 等看似“只读”的操作，在存在并发写时同样不安全——因为 map 的内部结构（如 bucket 数组、溢出链表、计数器）可能正在被重哈希或调整，此时读取长度或遍历可能读到中间态，造成 panic 或漏项。
- Go 不存在“部分线程安全”的 map：没有操作是“良性”或“可容忍”的竞态。所有未同步的并发 map 访问均属 bug。
✅ 正确做法有三种主流方案：
-
使用 sync.RWMutex（推荐用于读多写少场景）
var ( mu sync.RWMutex m = make(map[int]*User) ) // 读 mu.RLock() u := m[1] mu.RUnlock() // 写 mu.Lock() m[1] = &User{Name: "Charlie"} mu.Unlock() -
使用 sync.Map（适用于键值生命周期长、读写频率接近的场景）
var m sync.Map // 注意：key/value 类型为 interface{}，需 type assert m.Store(1, &User{Name: "David"}) if u, ok := m.Load(1); ok { u.(*User).Name = "Eve" // 修改值本身仍需自行同步 }⚠️ sync.Map 仅保证其自身方法调用（Load, Store, Delete 等）的线程安全，不保护 value 的内部状态。若存储的是指针（如 *User），对其解引用后的修改仍需额外同步。
采用通道（channel）或专用 goroutine 封装 map 访问（适合复杂逻辑）
通过消息传递将所有 map 操作序列化到一个 goroutine 中，彻底消除并发冲突。
? 总结：
Go 的 map 线程不安全不是“性能妥协”，而是设计选择——它避免了无处不在的锁开销，将并发控制权交还给开发者。永远不要依赖“好像没出错”来判断线程安全性。务必启用 -race 标志测试：
go run -race main.go go test -race ./...
只要存在未经同步的并发 map 读写，race detector 必定捕获。真正的线程安全，始于明确的同步契约，而非侥幸。
