代码评审与合并冲突不要丢掉排障上下文异步任务、下游调用和结构化日志如果没有共同的关联标识排障时很难拼回一次请求。合并冲突中context传递和 trace 关联代码看起来短却可能是可观测性的一部分不应被当成无关样板删除。评审时检查上下文是否断链评审时关注语义新 goroutine 是否继承取消信号跨进程调用是否传播 trace上下文日志是否记录受控错误类别。日志可以写请求 ID、阶段和脱敏错误不必写用户代码或令牌。字符串扫描只能发现明显缺失不能替代对生命周期的审查。反例是冲突解决后保留了普通日志却删除了 span 创建或上下文传递。服务仍能运行但慢请求与下游错误无法关联。对此应补充集成测试发起一个带 trace 的请求确认异步阶段和下游 span 仍可查询。验证还包括取消请求是否停止后台任务、日志是否能通过请求 ID 关联、敏感字段是否未被输出。把这些检查写入评审清单能让合并从“文本合上了”变成“诊断能力仍在”。队列任务只传递必要的关联信息操作时可在异步入口显式提取并注入关联字段而不是默认假定新 goroutine 会保留全部上下文。对必须跨队列传递的任务把 trace 或请求关联标识写进经过校验的任务元数据执行端创建新的 span 并链接到它。不要将整个请求对象序列化进队列其中可能含有敏感信息和不可用的取消句柄。合并后用一条受控请求验证入口、后台任务和下游调用在观测系统中能被串起错误日志只保留必要字段。若某段流程刻意不传播 trace也应记录原因避免后来的人把断链误认为系统问题。冲突处理前先分辨两段代码各自解决什么问题。有的改动在调整业务分支有的改动只是把错误包装为带阶段信息的日志手工选择“看起来更新的一边”很容易让后一类保护丢失。遇到共同修改同一调用点时最好回到两条提交的上下文和测试目标合并出两种意图而不是按行数更少的版本取舍。关联标识也不能成为新的泄露通道。请求 ID 应由受控组件生成或校验不能直接把用户提供的值原样写入日志和下游 headertrace baggage 只放有限、允许传播的键。评审时看见为了排障新增的字段应同时问它的来源、生命周期和脱敏规则。可观测性代码不是附属装饰它同样需要协议边界。测试中可以故意制造一次下游超时和一次队列取消观察日志与 trace 的关系是否仍完整。重点不是每条日志都出现而是同一个关联标识能串起入口判断、任务创建、重试或取消的决定。若错误被转换成业务响应也应保留可查的错误类别。这样冲突解决后即使行为变了评审者仍有客观证据判断诊断能力有没有退化。合并完成后再检查配置层。采样开关、日志字段白名单和传播 header 可能在代码之外冲突时同样容易被覆盖。代码保留了 span 并不代表线上一定会上报配置放宽了字段也可能泄露内容。把关键配置纳入变更审查并在测试环境验证最终生效值才能避免“本地看起来没问题”的假象。