直接读写全局变量会panic，因Go运行时检测到并发读写map/slice等非线程安全类型时主动终止程序以防止数据损坏；sync.RWMutex适用于读多写少场景，atomic.Value适用于单写多读且值类型固定的配置快照。
为什么直接读写全局变量会 panic
Go 的 map、slice、普通指针或结构体字段，只要被多个 goroutine 同时写（或一写一读），就可能触发 fatal error: concurrent map writes 或静默数据损坏。这不是偶发 bug，而是 Go 运行时主动检测到数据竞争后强制终止程序——自 1.6 起默认开启。你看到的崩溃，其实是保护机制在起作用。
sync.RWMutex：读多写少时的首选方案
如果你的全局变量是 map[string]string、map[int]struct{} 这类频繁读取但偶尔更新的缓存，sync.RWMutex 是最平衡的选择。它允许多个 goroutine 并发读，但写操作独占锁。
-
RLock()+RUnlock()用于安全读取，不阻塞其他读操作 -
Lock()+Unlock()用于写入，会阻塞所有读和写 - 必须用
defer确保解锁，否则极易死锁（比如函数中途 return） - 不要在锁内做耗时操作（如 HTTP 请求、文件读写），否则拖慢所有并发读
示例：
var cacheMu sync.RWMutex
var cache = make(map[string]int)
func Get(key string) (int, bool) {
cacheMu.RLock()
defer cacheMu.RUnlock()
v, ok := cache[key]
return v, ok
}
func Set(key string, val int) {
cacheMu.Lock()
defer cacheMu.Unlock()
cache[key] = val
}
sync/atomic.Value：单写多读且值类型固定时更轻量
当你的全局变量只是替换整个值（比如配置字符串、开关布尔值、结构体快照），且写操作极少（如启动时加载、定时刷新），sync/atomic.Value 比锁更高效——无锁、零分配、内存可见性由底层保证。
立即学习“go语言免费学习笔记（深入）”；
- 只能
Store()和Load()，不能做原子增减或字段级修改 - 类型必须一致：首次
Store()后，后续只能存同类型；不能先Store(int)再Store(string) - 适合场景：环境变量缓存、服务地址列表、JSON 配置结构体
- 注意初始化：未
Store()就Load()会 panic，建议init()中设默认值
示例：
var config atomic.Value // 存 *Config
type Config struct {
Timeout int
Debug bool
}
func init() {
config.Store(&Config{Timeout: 30, Debug: false})
}
func Update(newCfg *Config) {
config.Store(newCfg)
}
func GetConfig() *Config {
return config.Load().(*Config)
}
别踩这些坑
真正出问题的往往不是选错方案，而是细节失控：
- 把
sync.Mutex当成万能解药——它会让所有读也串行，高并发读场景下性能断崖下跌 - 在
defer Unlock()前 panic，导致锁永远不释放；务必确保锁生命周期严格绑定到函数作用域 - 用
sync.Map替代普通 map 却忽略它的开销：它专为「键值对极少更新、大量临时键」设计，常规缓存反而更慢 - 认为
*os.File或log.Logger自带线程安全就直接共享——它们只保证单次Write原子，复合操作（如fmt.Fprintf）仍需同步
最常被忽略的一点：全局变量本身不是问题，问题在于“谁在什么时候以什么方式访问它”。先理清读写频率、更新粒度和一致性要求，再选工具，而不是反过来。
