可以，但必须确保所有访问这些变量的代码路径都经过同一把 Mutex 的 Lock()/Unlock() 包裹；常见错误是漏锁、panic 导致未解锁、锁内耗时或嵌套锁；Mutex 不可复制。
sync.Mutex 能否保护多个变量？
可以，但必须确保所有访问这些变量的代码路径都经过同一把 Mutex 的 Lock() / Unlock() 包裹。常见错误是只锁一部分读写，或在 defer 中 unlock 却提前 return 导致锁未释放。
典型误用：
var mu sync.Mutex
var a, b int
func badUpdate() {
mu.Lock()
a = 1
// 忘记锁 b，或这里 panic → b 永远不更新
b = 2
mu.Unlock()
}
正确做法是把相关状态视为一个逻辑单元，统一加锁：
func goodUpdate() {
mu.Lock()
defer mu.Unlock()
a = 1
b = 2
// 所有共享变量操作都在临界区内
}
- 不要在锁内做耗时操作（如 HTTP 请求、文件 IO）
- 避免嵌套锁，否则易死锁；如需多把锁，按固定顺序获取
-
sync.Mutex不可复制，字段声明后直接使用，别用new(sync.Mutex)或赋值给另一个变量
sync.WaitGroup 为什么 Wait 总是提前返回？
根本原因是 Add() 调用时机不对 —— 必须在 goroutine 启动前调用，不能在 goroutine 内部调用。因为 Wait() 只等待计数归零，而 Add() 若在子 goroutine 里执行，主线程可能早已进入 Wait() 并发现计数仍是 0。
立即学习“go语言免费学习笔记（深入）”；
错误示例：
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
go func() {
defer wg.Done()
wg.Add(1) // ❌ 错！此时 wg 计数还没加，Wait 可能已开始
time.Sleep(time.Second)
}()
}
wg.Wait() // 立即返回
正确写法：
var wg sync.WaitGroup
for i := 0; i < 3; i++ {
wg.Add(1) // ✅ 必须在 go 前调用
go func() {
defer wg.Done()
time.Sleep(time.Second)
}()
}
wg.Wait() // 等待全部完成
-
Add()参数可为负数，但会导致 panic（计数变负），仅用Done()更安全 -
WaitGroup不能被复制，也不能在Wait()返回后再复用（Go 1.20+ 允许重用，但需确保无 goroutine 正在调用Done()） - 若需动态增减任务数，考虑用
errgroup.Group替代
sync.Once 是不是线程安全的初始化唯一方案？
是，且是 Go 标准库中唯一推荐的「单次初始化」机制。它内部用原子操作 + 互斥锁实现，比手写 if init == false { ... init = true } 更可靠，尤其在高并发下能避免重复初始化。
典型用途：全局配置加载、数据库连接池初始化、HTTP client 复用等。
var loadConfigOnce sync.Once
var config *Config
func GetConfig() *Config {
loadConfigOnce.Do(func() {
config = loadFromYAML("config.yaml") // 这个函数只会执行一次
})
return config
}
-
Do()接收的函数若 panic，Once会认为已执行完毕，后续调用不再触发 —— 所以务必在闭包内处理异常 - 不要把带参数的初始化逻辑直接塞进
Do()，容易捕获错误变量；建议封装成无参函数再传入 - 不需要手动管理
Once字段生命周期，它本身是零值安全的
sync.RWMutex 比 Mutex 快在哪？
快在「读多写少」场景下允许多个 goroutine 同时读，而 sync.Mutex 无论读写都互斥。但要注意：一旦有 goroutine 请求写锁，所有新来的读请求都会阻塞，直到写完成。
适用场景：缓存、配置表、状态快照等读频次远高于写频次的数据结构。
var rwmu sync.RWMutex
var cache = make(map[string]string)
func Get(key string) string {
rwmu.RLock() // ✅ 允许多个 goroutine 并发读
defer rwmu.RUnlock()
return cache[key]
}
func Set(key, value string) {
rwmu.Lock() // ❗写时独占，且会阻塞后续所有 RLock()
defer rwmu.Unlock()
cache[key] = value
}
- 不要在
RLock()后调用可能阻塞或耗时的函数（比如另一个锁、channel receive），否则会拖慢其他读操作 - 没有「升级锁」机制：不能从
RLock()直接转为写锁，必须先RUnlock()再Lock()，这中间存在竞态窗口 - 如果读写比例接近 1:1，
RWMutex可能比Mutex更慢，因内部状态更复杂
sync.WaitGroup 和 sync.Once 当作“语法糖”随意用，却没意识到它们对执行时序的强约束。比如在 http handler 里误用未重置的 WaitGroup，或在循环中反复创建 Once 实例——这些都不会报错，但结果不可预测。 
