直接读写全局变量在goroutine中会引发数据竞争，因“读-改-写”非原子且map等类型扩容时读写并发会导致panic；Go要求显式同步，如用sync.Mutex、RWMutex、atomic或sync.Map按场景选择。
为什么直接读写全局变量在 goroutine 中会出问题
Go 的 goroutine 是轻量级并发单元，但多个 goroutine 同时读写同一块内存（比如一个 int 或 map）时，不加同步会导致数据竞争（data race）。Go 工具链能检测到这类问题，运行时可能报错：fatal error: concurrent map writes 或触发 go run -race 报告竞争警告。
根本原因不是“Go 不支持并发”，而是 Go 要求你**显式声明临界区**——即哪些操作必须串行执行。这和 C/C++ 依赖程序员自觉加锁不同，Go 把竞争检测做进了工具链，逼你直面问题。
- 常见错误场景：用
map[string]int做计数器，多个goroutine同时执行counter[key]++ -
counter[key]++看似原子，实际是“读-改-写”三步，中间可被其他 goroutine 打断 - 即使只读不写，若同时有写操作，也可能读到脏数据或 panic（如
map扩容中被读）
sync.Mutex 的正确使用姿势
sync.Mutex 是最基础的互斥锁，但它本身不保护任何变量——它只提供“同一时间最多一个 goroutine 能进入某段代码”的能力。关键在于：锁的生命周期、作用域和配对必须严格。
- 锁对象通常作为结构体字段存在，而不是局部变量（否则每次调用都新建一把锁，完全无效）
-
Lock()和Unlock()必须成对出现；建议用defer mu.Unlock()防止遗漏 - 不要在锁持有期间做耗时操作（如 HTTP 请求、文件 IO），否则阻塞其他 goroutine
- 避免锁嵌套或跨函数传递锁状态，容易死锁
type Counter struct {
mu sync.Mutex
v int
}
func (c *Counter) Inc() {
c.mu.Lock()
defer c.mu.Unlock()
c.v++
}
func (c *Counter) Value() int {
c.mu.Lock()
defer c.mu.Unlock()
return c.v
}
什么时候该用 RWMutex 而不是 Mutex
当读操作远多于写操作，且读操作本身不修改数据时，sync.RWMutex 可显著提升并发吞吐。它允许多个 goroutine 同时读（R Lock），但写操作（Lock）会独占——即“多读单写”模型。
立即学习“go语言免费学习笔记（深入）”；
- 典型适用场景：配置缓存、白名单
map、状态只读快照 - 误用风险：在
R Lock持有期间调用可能修改数据的函数（哪怕只是间接修改），会导致数据竞争 - 注意：
RWMutex的写锁会阻塞新读锁请求，但已持有的读锁不释放前，写锁会一直等待
type Config struct {
mu sync.RWMutex
data map[string]string
}
func (c *Config) Get(key string) string {
c.mu.RLock()
defer c.mu.RUnlock()
return c.data[key]
}
func (c *Config) Set(key, value string) {
c.mu.Lock()
defer c.mu.Unlock()
c.data[key] = value
}
比 Mutex 更安全的替代方案：sync/atomic 和 sync.Map
对于简单类型（int32、int64、uint64、指针），sync/atomic 提供无锁原子操作，性能更高且天然线程安全；而 sync.Map 是为“读多写少 + 键值生命周期长”设计的并发安全 map，内部混合使用原子操作与分段锁。
-
atomic不能用于结构体或切片，仅限固定大小整型和指针；atomic.LoadInt64(&x)比加锁读更快 -
sync.Map不适合高频遍历或需要range的场景，它的Range方法是快照语义，不保证实时性 - 别为了“看起来高级”强行用
sync.Map替代普通map + Mutex——如果写操作频繁，sync.Map的性能反而更差
真正需要警惕的是：没有银弹。Mutex 明确、可控、易调试；atomic 高效但适用面窄；sync.Map 隐藏了锁细节，出问题时更难定位。选哪个，取决于你的访问模式和可维护性要求。
