gh pr view 128 --json additions,deletions,changedFiles gh pr diff 128 --name-only | wc -l
重构分支攒了两周，PR 里 83 个文件、4200 行新增。挂在评审列表三天，只有两个人留了「先看看」，最后作者自己点通过合并。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，改动没有按可评审的粒度切分，评审人打开就看到一片红绿，判断不了从哪看起。团队没有单次 PR 行数上限，攒着一起提成了习惯。
围绕「PR 规模过大」排查时，命令行跑一遍比在面板里点十次有用，面板会替你做掉不少隐式操作。改完隔一天再看一次，当场正常不代表能稳住。
测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
处理上按这个顺序：把重构拆成不改行为的准备提交和真正的逻辑改动两批；单次 PR 控制在 400 行以内 超过就先拆；大改动提前写一段说明 标明阅读顺序；约定 24 小时内必须有人认领 没人认领就升级到组长。
改完只确认一件事：拆分后每个 PR 在 24 小时内至少有一条实质评审意见，合并前 changedFiles 不超过 15。