Go 中 map 套指针本身合法但并发不安全，关键在于对 map 本身的读写是否受保护；多个 goroutine 同时写同一 map（增、删、改 key）会触发 panic，而修改指针指向的值则需单独同步。
Go 语言中，map 套指针本身是语法合法的，但并发读写时是否安全，不取决于“套没套指针”，而取决于 map 本身的并发访问是否受保护。简单说：只要多个 goroutine 同时对同一个 map 进行写操作（哪怕只是修改指针字段），就存在数据竞争风险，会触发 panic 或未定义行为。
map 存的是指针 ≠ map 是线程安全的
例如：
type User struct{ Name string }
var m = make(map[int]*User)
m[1] = &User{Name: "Alice"}
这里 m 存的是 *User 指针，但 m 本身仍是普通 map。如果你在两个 goroutine 中同时执行 m[1] = &User{...} 或 delete(m, 1)，就会触发 fatal error: concurrent map writes。
立即学习“go语言免费学习笔记（深入）”；
注意：即使只读不写，如果一边在写、一边在读，也属于并发不安全 — Go 的 map 读操作在扩容期间可能 panic。
指针嵌套本身不增加并发风险，但容易掩盖共享状态
比如：
type Cache struct { data map[string]*Item }
type Item struct { value int; mu sync.RWMutex }
看起来每个 Item 都有自己的锁，很安全？错。如果多个 goroutine 同时调用 cache.data["x"] = newItem，还是在写 map，照样竞争。而如果只改 cache.data["x"].value，那没问题 — 因为改的是指针指向的 struct 字段，不是 map 本身。
关键分清： - 写 map（增、删、改 key）→ 必须同步 - 写指针指向的值（如 p.Name = "Bob"）→ 只要该值不被其他 goroutine 同时写，就无需额外保护 map
安全做法：按场景选方案
- 纯读多写少 → 用 sync.RWMutex 包一层 map，读用 RLock()，写用 Lock()
- 高频读写且键固定 → 考虑 sync.Map（适合低更新、高并发读；但不支持遍历、无 len、接口较重）
- 需要强一致性或复杂逻辑 → 改用 channel + 单独 goroutine 管理 map（即“owner goroutine”模式）
- 结构体字段级并发 → 对指针指向的 struct 加锁（如上面 Item.mu），和 map 锁解耦
基本上就这些。指针只是值，map 才是并发敏感点。别被“套指针”带偏了重点 — 关键看谁在动 map 本身。
