不需要，但必须确保首次使用前完成初始化且不并发读写字段；sync.Mutex零值有效，应直接声明而非指针初始化；复制已加锁的Mutex会丢失锁状态，故禁止复制；mu.Lock()后遗漏Unlock会导致后续goroutine永久阻塞。
Go里sync.Mutex必须和共享变量在同一个goroutine初始化吗？
不需要，但必须确保首次使用前已完成初始化，且不能在锁保护外并发读写其字段。常见错误是把Mutex作为结构体字段却忘记导出或零值可用——sync.Mutex是可复制的，零值本身就是有效未锁定状态。
正确做法是直接声明或嵌入：
type Counter struct {
mu sync.Mutex
value int
}
而不是new(sync.Mutex)或指针初始化。因为sync.Mutex不包含指针或系统资源，复制它不会导致锁失效，但会丢失锁状态（比如你复制了一个已加锁的Mutex，副本是未锁定的）——所以永远别复制正在使用的Mutex。
为什么mu.Lock()后忘了mu.Unlock()会导致死锁？
不是“导致死锁”，而是让后续所有尝试mu.Lock()的goroutine永久阻塞。Go运行时检测不到这种逻辑错误，也不会panic。只有当你用go test -race或sync.Mutex配合defer时才容易暴露问题。
- 最稳妥写法是
mu.Lock(); defer mu.Unlock()，哪怕函数有多个return路径 - 避免在循环内反复
Lock/Unlock，这会放大锁竞争；应把整个临界区包住 - 不要在持有锁时调用可能阻塞或重入的函数（如HTTP请求、另一个
Lock()），否则极易形成等待链
sync.RWMutex比sync.Mutex快在哪？适用什么场景？
读多写少时，RWMutex允许多个goroutine同时读，但写操作会独占并阻塞所有读写。它的开销略高于Mutex，但吞吐量在高并发读场景下显著提升。
典型适用场景：
- 配置缓存（读远多于更新）
- 状态映射表（频繁查询，偶尔增删）
- 避免为每次读都加完整互斥锁
注意：RWMutex.RLock()和RUnlock()必须配对，且不能在持有RLock时调用Lock()，否则会死锁。反过来可以：持有Lock()期间调用RLock()是允许的（但没必要）。
用sync.Once替代Mutex做单次初始化靠谱吗？
靠谱，而且更轻量、更安全。sync.Once本质就是带原子控制的懒加载，内部用了Mutex但对外屏蔽了锁细节。它保证Do()里的函数只执行一次，无论多少goroutine并发调用。
var once sync.Once
var config *Config
func GetConfig() *Config {
once.Do(func() {
config = loadConfigFromDisk()
})
return config
}
比起手写if config == nil { mu.Lock(); if config == nil { config = ... }; mu.Unlock() }，Once不易出错，也没有双重检查锁（DCL）的内存模型陷阱。但它只适用于「纯初始化」，不能用于需要重复加锁的业务逻辑。
真正容易被忽略的是：一旦Once.Do()中panic，该Once就永久标记为“已完成”，后续调用不会重试——所以初始化函数里要自己recover或确保不panic。
