一个改提示语的 PR 里混进了 400 行目录结构调整，评审人翻了前 20 行就点了通过。上线后配置加载失败，问题正好在那 400 行里。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，作者顺手把本地未完成的重构一起提交了，没有按主题拆分。评审看到标题以为是小改动，投入的注意力也少。
碰到「提交混入无关改动」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
git diff --stat origin/main...HEAD git log --oneline origin/main..HEAD
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
具体做法是，提交前用 git diff 过一遍 确认改动都属于同一个主题；无关改动拆到单独分支 单独提 PR；开启提交前检查 单次提交超过 300 行提示确认；评审时先看文件列表 有意外文件就要求拆。
最后用这个标准收尾，PR 的文件列表和标题描述一致，出现无关文件时能在评审阶段被打回。