投票计数器为什么加了 Mutex 还会出错？
根本原因不是没加锁，而是锁的生命周期或作用域错了。常见写法是把 sync.Mutex 声明在函数内、或作为局部变量传参，导致每次调用都新建一把锁，完全起不到保护作用。
正确做法是让 Mutex 和被保护的数据绑定在同一结构体里，且该结构体实例需全局共享（比如作为 handler 的字段）。
-
sync.Mutex必须是结构体字段，不能是函数参数或临时变量 - 读写共享数据前必须调用
mu.Lock()/mu.RLock()，结束后立刻mu.Unlock()/mu.RUnlock() - 别在 defer 里 unlock 后还继续操作共享数据（defer 执行时机可能晚于 return）
// ❌ 错误：每次 handle 都新建 mutex
func handleVote(w http.ResponseWriter, r *http.Request) {
var mu sync.Mutex
mu.Lock()
votes["yes"]++
mu.Unlock()
}
// ✅ 正确：mutex 是结构体成员，随 handler 实例复用
type VoteHandler struct {
mu sync.RWMutex
votes map[string]int
}
用 RWMutex 还是 Mutex？看读写比例
投票系统里，查票数（读）远多于提交投票（写），这时候用 sync.RWMutex 能显著提升并发吞吐。但要注意：RWMutex 的写锁会阻塞所有新读锁，而读锁之间不互斥——这点和直觉相反，容易误判性能。
- 读多写少（如每秒 1000 次查询 + 5 次投票）→ 优先
RWMutex - 写操作频繁（比如实时统计+广播）→
Mutex更简单，避免RWMutex的饥饿风险 -
RWMutex.RLock()不会阻塞其他RLock()，但会阻塞后续Lock()；反之，Lock()会阻塞所有新锁请求
HTTP handler 中怎么安全地更新和返回投票结果？
Go 的 HTTP server 默认为每个请求启动 goroutine，所以多个请求同时修改 votes 映射时，即使有锁，也得确保映射本身不被并发写（Go 的 map 并发读写 panic 是 runtime 级错误，不是竞态检测能发现的）。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 不要直接暴露原始
map[string]int给多个 goroutine 读写 - 读操作用
RWMutex.RLock()+defer mu.RUnlock()，然后 copy 一份数据再返回（避免锁住期间序列化阻塞其他请求） - 写操作用
Lock()，更新前检查合法性（如选项是否存在），更新后立即 unlock - 别在锁内做 HTTP 请求、数据库调用等耗时操作
func (h *VoteHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
if r.Method == "POST" {
h.mu.Lock()
// 验证 option、更新计数...
h.votes[option]++
h.mu.Unlock()
return
}
h.mu.RLock()
data := make(map[string]int)
for k, v := range h.votes {
data[k] = v
}
h.mu.RUnlock()
json.NewEncoder(w).Encode(data)
}
本地测试并发安全时，go test -race 报什么才算真问题？
-race 是必要但不充分的验证手段。它只能捕获运行时发生的竞态，没法发现逻辑锁遗漏（比如忘了加锁）、死锁、或锁粒度太粗导致的性能瓶颈。
- 看到
Read at ... by goroutine X / Previous write at ... by goroutine Y→ 真实竞态，必须修复 - 没报 race 但压测时结果错乱（如总票数对不上）→ 很可能是漏锁、或锁范围没覆盖全部共享路径
- 压测 QPS 上不去，
pprof显示大量 goroutine 阻塞在sync.Mutex.Lock→ 锁粒度太粗，考虑拆分结构体或改用原子操作
真正难搞的是那些只在高并发、特定调度顺序下才触发的逻辑漏洞——它们不会被 race detector 捕获，也很难复现。上线前至少用 ab -n 1000 -c 100 过一遍核心接口，比单靠工具更实在。
