Go中引用类型（如slice、map、channel等）不保证并发安全，多goroutine读写需显式同步；推荐按场景选用sync.RWMutex、sync.Map、sync/atomic或channel。
引用类型本身不保证并发安全
Go 中的切片（slice）、map、channel、指针、函数、接口等属于引用类型，但它们的“引用”特性只表示底层数据结构共享同一块内存，并不意味着操作是原子的或线程安全的。比如多个 goroutine 同时对一个 map 进行读写，会直接触发 panic（fatal error: concurrent map writes）；对切片追加元素（append）也可能因底层数组扩容导致数据竞争。
哪些操作必须加锁
以下情况需要显式同步控制：
- 多个 goroutine 同时写同一个 map（哪怕只是写不同 key）——必须用
sync.RWMutex或sync.Map - 一个 goroutine 写 + 其他 goroutine 读 map —— 仍需锁，因为写操作可能引发扩容，破坏正在读取的迭代状态
- 对非并发安全的结构体字段（如含 slice/map 的 struct）做复合操作（如先查再改）—— 即使字段是引用类型，整体逻辑也需锁保护
- 共享指针指向的数据被多 goroutine 修改（如
*int被多个 goroutine 增减）—— 基础类型操作虽小，但非原子，需sync/atomic或互斥锁
推荐的并发安全方案
优先按场景选合适工具，不盲目上 sync.Mutex：
-
读多写少的 map：用
sync.RWMutex包裹原生 map，读用RLock，写用Lock -
简单键值缓存：用标准库
sync.Map（适合低频写、高频读，但不支持遍历和 len，且无泛型约束） -
计数器、标志位等基础操作：用
sync/atomic（如atomic.AddInt64、atomic.LoadPointer），零分配、无锁、高效 - 天然并发安全的类型：channel 是 Go 原生支持并发通信的机制，用 channel 传递数据比共享内存更符合 Go 的设计哲学（Do not communicate by sharing memory; instead, share memory by communicating.）
避免踩坑的关键习惯
很多数据竞争不是因为不会加锁，而是没意识到要加：
立即学习“go语言免费学习笔记（深入）”；
- 不要假设“只读”就绝对安全——如果其他 goroutine 正在写，没锁的读仍是竞态
- 切片的
append不是原子操作，多 goroutine 并发append同一个切片会丢数据或 panic - 使用
-race编译参数运行程序（go run -race main.go），它能动态检测大部分数据竞争问题 - 结构体嵌套引用类型时，锁的粒度要覆盖整个业务逻辑，而不是只锁某个字段
