合并冲突时别把输入输出放进锁里

合并冲突时别把输入输出放进锁里合并冲突最危险的地方不一定是编译错误而是两个局部正确的改动被拼在一起后改变了并发边界。例如远程调用、数据库查询或大循环落在Lock和Unlock之间会让锁持有时间取决于外部系统其他请求只能排队等待。评审这类改动时先明确共享状态是什么再把读取、远程请求和计算放在锁外。必要时先在锁内复制当前状态解锁后执行慢操作最后在短临界区内按版本号或条件提交结果。不要为了避免锁竞争直接改成无锁实现除非能证明内存安全和一致性。mu.RLock() snapshot : state.clone() mu.RUnlock() result, err : fetch(ctx, snapshot.Key) // I/O 在锁外 if err ! nil { return err } mu.Lock() if state.Version snapshot.Version { state.Result result } mu.Unlock()慢锁告警可以帮助定位问题但阈值要依据服务目标设置而且记录堆栈会产生开销宜按采样或在诊断开关下启用。sync.RWMutex的使用也应以 profile 为依据读锁多不代表一定优于普通互斥锁。提交前至少运行受影响包的单测和竞态检测若改动涉及热点路径再比较同一负载下的 benchmark、block profile 与 mutex profile。性能数字必须标注环境、并发与数据集不能脱离条件作为结论。