应优先用无锁或低锁结构替代互斥锁：sync.RWMutex、sync.Map、sync/atomic、channel；缩小锁粒度；用原子指针+只读副本消除读锁；结合context控制争抢。
用无锁数据结构替代互斥锁
Go 标准库提供了不少线程安全的无锁或低锁开销类型，能直接避开 sync.Mutex 的等待。比如：
• 读多写少场景优先用 sync.RWMutex，读操作不阻塞其他读，仅写时排他；
• 频繁增删查、无需强一致性时，可用 sync.Map（内部分段锁+原子操作，比全局 mutex 更轻）；
• 计数类操作尽量走 sync/atomic，如 atomic.AddInt64(&counter, 1)，完全无锁且性能极高；
• 通道（channel）本身是 Go 原生并发原语，适合协程间传递数据或信号，避免手动加锁协调。
缩小锁粒度与作用域
锁不是越早加越好，而是越细、越短越好。常见误区是整个函数或大结构体共用一把锁。
• 按数据域拆分：比如用户结构体含 name、email、balance，若 balance 更新频繁而 name 很少变，就为 balance 单独配一个 sync.Mutex；
• 按逻辑边界加锁：只在真正访问/修改共享状态的几行代码前后加锁，而不是包裹整个业务流程；
• 避免在锁内做耗时操作：如网络请求、文件读写、复杂计算——这些应移出临界区，否则其他 goroutine 长时间等待。
用只读副本 + 原子指针替换减少竞争
当配置、路由表、缓存元信息等数据整体只读、偶有更新时，可彻底消除读锁：
• 维护一份不可变结构体（如 type Config struct{...}），每次更新生成新实例；
• 用 atomic.Value 存储指向该结构体的指针，读取时 v.Load().(*Config)，写入时 v.Store(&newCfg)；
• 所有读操作零锁、无等待，写操作仅需一次原子赋值，天然规避读写竞争。
合理使用 context 控制争抢行为
当多个 goroutine 可能同时尝试获取同一资源（如初始化单例、抢占分布式锁），可通过超时或取消机制降低无效等待：
• 加锁前先用 context.WithTimeout 设定最大等待时间，超时则放弃或降级；
• 对非关键路径的锁尝试，用 mutex.TryLock()（需自行封装或用第三方库如 gofork/sync）避免死等；
• 结合 sync.Once 处理一次性初始化，它内部已优化为无竞争路径，比手写双检锁更安全高效。
基本上就这些。锁不是不用，而是要让它“存在感更低”——要么绕过去，要么缩到最小，要么让等待变得可退可弃。Golang 并发模型的优势，正在于给你足够多的轻量工具去替代粗粒度同步。
