sync.Mutex不能保护goroutine创建时的竞态，因为锁只作用于加锁到解锁间的代码，而go语句启动的新goroutine执行时机异步，主goroutine释放锁后其内部逻辑可能尚未执行。
为什么 sync.Mutex 不能保护 goroutine 创建时的竞态
很多人以为只要在 go 语句前加锁，就能保证后续操作线程安全。其实不是：锁只对加锁/解锁之间的代码段起作用，而 go func() { ... }() 启动的是新 goroutine，其内部执行时机完全异步。一旦 go 语句返回，主 goroutine 就可能立刻释放锁，此时新 goroutine 还没开始执行，更别说访问共享变量了。
典型错误写法：
mu.Lock()
go func() {
// 这里读写 sharedData 是不安全的
fmt.Println(sharedData)
}()
mu.Unlock() // 锁已释放，但上面的 goroutine 可能还没执行到 print
正确思路是把需要保护的数据访问逻辑，完整包裹在锁的临界区内 —— 或者改用通道传递数据，避免共享。
- 若必须在 goroutine 中读写共享变量，应在 goroutine 内部获取锁（注意避免死锁）
- 优先考虑用
chan把数据“推”给 goroutine，而非让它“拉”取全局状态 - 对一次性初始化场景，用
sync.Once比手写双检锁更可靠
sync.RWMutex 什么时候比 sync.Mutex 更合适
sync.RWMutex 的价值只在「读多写少」且读操作本身耗时不短时才明显。如果读操作只是简单取一个字段，用 RWMutex 反而因额外的 goroutine 状态管理带来开销；但如果读操作涉及遍历 map、序列化结构体或调用外部方法，它就值得引入。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
关键限制：不能嵌套使用读锁和写锁。例如在持有 RLock() 期间调用另一个也尝试 Rlock() 的函数，没问题；但若该函数内部试图 Lock()，就会死锁 —— 因为写锁会等待所有读锁释放，而当前 goroutine 持有读锁又在等写锁。
- 写操作频率超过 5%～10%，
RWMutex的优势通常消失 -
RLock()和Unlock()必须成对出现，漏掉会导致后续所有写操作永久阻塞 - 不要在 defer 中无条件调用
mu.RUnlock()，除非你能确保前面一定调用了RLock()
channel 和 mutex 不是二选一，而是分工不同
初学者常陷入“该用 channel 还是 mutex”的纠结，其实 Go 官方文档早说清楚了：“Do not communicate by sharing memory; instead, share memory by communicating.” 这句话不是禁止用锁，而是强调：goroutine 间协作的主线应是 channel，锁只用于保护局部、高频、低延迟的内存访问。
比如一个计数器更新，用 sync/atomic 最轻量；一个配置热更新，用 channel 通知 reload 比轮询 + 锁更清晰；而一个带复杂校验逻辑的订单状态机，用 mutex 保护状态字段 + channel 触发异步处理才是合理组合。
- channel 适合跨 goroutine 的事件通知、任务分发、结果收集
- mutex 适合保护某个 struct 的字段、缓存 map 的增删查、文件句柄池等资源池状态
- 混合使用时，避免在 channel 的发送/接收逻辑里长时间持锁（易造成 sender/receiver 阻塞）
为什么 defer mu.Unlock() 在循环里容易出错
在 for 循环中写 for _, v := range data { mu.Lock(); defer mu.Unlock(); ... } 是常见误用。因为 defer 是函数退出时才执行，不是大括号结束就执行 —— 所有 defer 语句会在函数 return 前集中执行，导致第一次迭代后锁未释放，后续迭代直接卡死。
正确方式只有两种：显式配对，或把临界区抽成独立函数让 defer 自然生效。
for _, v := range data {
mu.Lock()
process(v)
mu.Unlock() // 必须手动 unlock
}
- defer 适合单次进入、单次退出的临界区，不适合循环内多次进/出
- 若逻辑复杂想用 defer，可封装为匿名函数：
func() { mu.Lock(); defer mu.Unlock(); process(v) }() - 静态检查工具如
go vet无法捕获这种逻辑错误，靠测试或 code review 发现
sync.Mutex 保护整个配置中心，会导致所有配置查询互相阻塞；而按配置 key 分片加锁，又可能让相关配置的一致性难以维护。这个权衡没有银弹，得看读写比例、延迟敏感度、以及你愿不愿意为一致性多写几行协调代码。 
