sync.mutex 是并发访问共享变量的强制护栏，必须在读写前加锁，否则必然触发 data race；实操需注意值类型传递、正确加解锁配对、避免锁内耗时操作、优先用 rwmutex 优化读多写少场景，并明确锁保护的是内存而非指针本身。
sync.Mutex 必须在读写共享变量前加锁
不加锁就并发读写，data race 几乎必然发生，Go 的 go run -race 会立刻报出类似 Read at 0x00c000010240 by goroutine 7 的错误。锁不是可选配件，是并发访问同一变量时的强制护栏。
实操建议：
-
sync.Mutex是值类型，别用指针传参（除非你明确要共享锁本身）；结构体里直接嵌入sync.Mutex最安全 - 加锁位置必须包裹「所有可能读或写共享变量」的代码段，哪怕只有一行
count++—— 它本质是读+写两步，不加锁就是竞态 - 避免在锁内做耗时操作：比如调用 HTTP 请求、读文件、或长时间循环；否则其他 goroutine 会长时间阻塞
Unlock 必须和 Lock 成对出现，且不能重复 Unlock
忘记 Unlock() 会导致死锁；重复调用 Unlock() 会 panic：sync: unlock of unlocked mutex。这不是“偶尔出错”，是运行时确定崩溃。
实操建议：
- 用
defer mu.Unlock()是最稳妥的方式，放在Lock()后立即写，能覆盖 return、panic 等所有退出路径 - 不要跨函数传递未解锁的
sync.Mutex；更不要在一个函数里Lock()，在另一个函数里Unlock() - 如果逻辑分支多（比如 if/else 中有提前 return），仍坚持 defer —— 它不会因为 return 而跳过
读多写少场景下，优先考虑 sync.RWMutex 而非 Mutex
当共享数据被大量并发读、极少写时，用 sync.Mutex 会让所有读操作排队，白白牺牲吞吐。而 sync.RWMutex 允许多个 goroutine 同时读，只在写时排他。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- 读操作用
RLock()+RUnlock()，写操作仍用Lock()+Unlock() -
RUnlock()必须配对RLock()，同样推荐defer mu.RUnlock() - 注意：一个 goroutine 持有
RLock()时，另一个 goroutine 调用Lock()会阻塞，直到所有RLock()释放 —— 这是设计使然，不是 bug
sync.Mutex 不能保护指针指向的内容
这是最常被忽略的坑：声明 var mu sync.Mutex 并保护了 ptr 变量本身，但没保护 *ptr 指向的内存。多个 goroutine 仍可能并发修改 *ptr，导致数据竞争。
实操建议：
- 如果
ptr是指向结构体的指针，且你要保护该结构体字段，锁应该放在结构体内（如type Counter struct { mu sync.Mutex; n int }），而不是锁ptr变量 - 切片、map、channel 本身是引用类型，但它们的底层数据结构仍需显式保护；例如并发写
m[key] = val，必须锁住整个 map 操作，不能只锁赋值语句前后的几行 - 没有银弹：锁粒度太粗影响性能，太细容易漏；从最小必要范围开始，用
-race验证，再逐步调整
真正难的不是写 mu.Lock()，而是准确识别「哪块内存正在被谁以什么方式访问」—— 多数竞态问题，根源不在锁怎么用，而在共享状态的边界没想清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
