Go中使用sync.Mutex保护共享资源需明确共享数据、统一封装访问逻辑、读写均加锁、避免死锁与粒度失当、读多写少用RWMutex、简单原子操作优先atomic，并用-race检测竞态。
使用 Go 的 sync.Mutex 是保护共享资源、避免并发读写冲突最直接有效的方式。关键不是“加锁”本身，而是明确哪些数据是共享的、谁在读/写、锁的粒度是否合理、以及是否遗漏了临界区。
明确共享变量并封装访问逻辑
不要让多个 goroutine 直接读写同一个变量。把共享数据（如 map、计数器、配置结构体）定义为包级或结构体字段，并通过方法控制访问。
- 避免：全局裸变量
var counter int被多个 goroutine 直接 ++ - 推荐：定义结构体 + mutex + 方法，例如：
mu sync.Mutex
val int
}
func (c *Counter) Inc() {
c.mu.Lock()
c.val++
c.mu.Unlock()
}
func (c *Counter) Get() int {
c.mu.Lock()
defer c.mu.Unlock()
return c.val
}
读写都必须加锁，不能只锁写不锁读
即使只是读取共享数据，也必须加锁。因为 Go 内存模型不保证未同步读操作能看到最新写入 —— 可能读到脏数据、零值，甚至触发 panic（比如读 map 时被另一个 goroutine 并发修改）。
- 错误示例：
if counter > 0 { ... }（没锁，可能刚判断完 counter 就被改了） - 正确做法：所有访问（包括
==、len()、遍历）都在锁内完成 - 注意：
defer mu.Unlock()在函数开头加锁后立即写，避免忘记解锁
避免死锁和锁粒度陷阱
死锁常发生在嵌套加锁顺序不一致，或锁住后调用可能再次加同一把锁的函数。锁太粗会降低并发性，太细则易出错。
立即学习“go语言免费学习笔记（深入）”；
- 按固定顺序获取多把锁（如总是先 lock A 再 lock B）
- 不要在持有 mutex 时调用不可控的外部函数（如 HTTP 请求、数据库查询），它们可能阻塞或回调本对象
- 考虑读多写少场景：用
sync.RWMutex，允许多个 reader 并发，writer 独占 - 若只做简单原子操作（如 int64 计数），优先用
sync/atomic，比 mutex 更轻量
用 go tool race 检测竞态条件
光靠人工检查很难覆盖所有并发路径。每次测试或运行服务时加上 -race 标志：
go test -race ./...
它会在运行时检测实际发生的竞态访问，并打印出读写 goroutine 的堆栈，是最可靠的验证手段。
