处理并发代码冲突合并文本之前先合并行为并发相关的合并冲突最容易给人错觉选定一侧改动代码能编译冲突就算解决了。可 channel 的关闭顺序、锁的所有权、取消传播和错误返回都属于行为约束机械合并后仍可能在压力下出现 goroutine 泄漏、死锁或偶发的错误结果。处理这类冲突时先不要急着点“接受当前更改”。先读清双方各自改变了什么并用一句话写下需要保留的约束谁创建并关闭 channel生产者何时停止消费者取消后发送端如何退出哪一层负责释放锁与资源。只有这些问题有答案代码行的取舍才有依据。先定位双方修改的意图一侧可能新增了 context 取消另一侧可能调整了结果汇总两段代码看起来能拼在一起实际却可能让一个 goroutine 提前返回、另一个仍阻塞在发送上。阅读冲突周边代码时要沿着数据和控制流往上、往下看不要只看冲突标记中的几行。对 channel 来说明确关闭者尤其重要。通常只有发送端或拥有者负责关闭多个地方尝试关闭会引发 panic没有人关闭时等待 range 的消费者又可能永远不退出。对锁也是一样谁获取谁释放异常和取消路径是否也经过释放不能在合并后变成模糊责任。错误传递需要有唯一出口。若一个分支直接 return另一个分支仍在向结果 channel 写错误调用方可能只看到部分状态。把成功、错误、超时和取消路径逐一画出来往往比盯着 diff 更快发现遗漏。接收端支持取消不等于整条链路可取消在等待结果时监听 context 很常见但消费者提前返回后生产者如果还无条件向无缓冲 channel 发送就会永久阻塞。解决方式取决于语义发送端也监听取消使用有边界的缓冲或由专门的协调者负责回收结果。不能只在接收端加一个分支就假定问题结束。缓冲 channel 也不是自动修复。它只能吸收有限数量的结果缓冲满后仍会阻塞而且容易掩盖没有消费者的问题。缓冲大小要与并发模型和最大在途结果对应不能随手设一个很大的数。同样地context 取消通常是“请求方不再等待”的信号不保证所有外部操作立刻停止。调用下游时需要传递 context循环计算中需要设置检查点无法取消的动作则要通过任务状态或幂等语义避免重复影响。用最小场景验证最终合并结果冲突解决后先看最终 diff确认没有遗留冲突标记、重复的 defer 或被误删的清理逻辑。接着写一个尽可能小的场景覆盖至少三种结局正常产生结果、超时或取消、生产者报错。测试不必模拟整个服务但要能让关键 goroutine 真正并发运行。为测试加上合理的超时避免死锁时 CI 永久挂起。出现过的竞态和阻塞应保留为回归用例不要只靠一次人工复现。相关单元测试、带竞态检测的测试和受控的集成测试可以分别覆盖不同层面功能、共享内存访问和外部协作。竞态检测没有发现问题也不能证明并发设计完全正确。它依赖实际执行路径逻辑上的等待循环、错误关闭顺序和资源泄漏仍需靠行为审查与针对性测试发现。把并发变更当作接口变更审查并发控制逻辑改变了调用方能期待的时序和失败语义即使函数签名没有变也应按接口变更审查。说明取消后返回什么、是否仍可能有后台工作、错误如何汇总能让后续维护者不必从 goroutine 栈里猜意图。CI 可以阻止冲突标记进入仓库也能运行测试却无法自动判断“此时谁应该关闭 channel”。人的审查应聚焦这些不变量而不是只确认格式和编译通过。把文本冲突还原成行为问题再处理能显著降低合并后才发现偶发故障的风险。