必须用 sync.Mutex 而不是 chan 的场景是：多个 goroutine 需反复读写同一结构体字段（如 map[string]int 计数器）且操作非原子时，chan 会增加复杂度、延迟和调试难度；sync.Mutex 开销更低，尤其适合高频小操作。
Go 语言中，内存共享本身不是问题，问题出在「未加保护的并发读写」——sync.Mutex 和 sync.RWMutex 是最直接、最可控的解法，而非依赖 chan 或 atomic 去绕开它。
什么时候必须用 sync.Mutex 而不是 chan
当多个 goroutine 需要反复读写同一块结构体字段（比如计数器、状态标志、缓存 map）、且操作不是原子单步时，chan 会显著增加复杂度和延迟。例如：
- 你有一个
map[string]int用于统计请求路径频次，100 个 goroutine 同时执行m[path]++→ 必须加锁，否则 panic 或数据错乱 - 用
chan实现类似逻辑需额外 goroutine 消费更新请求，吞吐下降、代码分散、调试困难 -
sync.Mutex的开销远低于跨 goroutine 通信，尤其在高频率小操作场景下
sync.RWMutex 的读写权重判断很关键
它只在「读多写少」且读操作耗时不长时才比 sync.Mutex 有优势。误用反而更慢：
- 如果写操作频繁（比如每秒上百次），
RWMutex的写饥饿风险上升，甚至比普通Mutex更卡 - 如果读操作本身很重（如遍历大 map + 序列化），持有
RLock()时间过长，会阻塞后续写操作，失去并发意义 - 简单判断：读写比例 > 10:1 且单次读 RWMutex
别把 atomic 当万能药，它只适用于极窄场景
atomic 包仅支持基础类型（int32/int64/uint32/uintptr/unsafe.Pointer）的单操作原子性，且要求对齐和平台支持：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
atomic.AddInt64(&counter, 1)安全，但counter++不安全，counter = counter * 2也不安全（非单原子） - 无法用于结构体字段、map 元素、切片元素等复合操作；试图用
atomic.Value存 map 并不解决并发写 map 本身的 panic - 32 位系统上
int64的 atomic 操作可能被拆成两次 32 位写，导致中间态错误 —— 必须确认GOARCH支持
最容易被忽略的坑：mutex 的生命周期与逃逸
锁对象本身不能是局部变量（函数内声明），否则每次调用都新建一个互斥锁，完全起不到保护作用：
func badHandler() {
var mu sync.Mutex // ❌ 每次调用都是新锁，无效
mu.Lock()
// ...
}正确做法是将 sync.Mutex 作为结构体字段或包级变量声明，确保所有 goroutine 访问的是同一个实例。另外，若结构体含 sync.Mutex 字段，该结构体不可被复制（包括作为函数参数传值、赋值给新变量），否则锁状态丢失：
type Counter struct {
mu sync.Mutex
n int64
}
var c Counter
c.mu.Lock() // ✅
d := c
d.mu.Lock() // ❌ 锁状态未复制，d.mu 是全新未锁定的锁 
