评审优先级为什么要排序
评审时间有限，注意力必须按影响面分配：核心逻辑与数据路径优先，其次是接口与兼容性、测试质量，最后才是命名、文档与风格细节。同一份 diff 里，资金、权限、数据相关的改动出错代价最高，值得逐行核对；格式问题交给工具就行。
基本信息
| 排序依据 | 影响面与出错代价 |
|---|---|
| 第一优先 | 核心逻辑、数据路径、权限与资金相关 |
| 第二优先 | 接口兼容性、错误处理、测试质量 |
| 末位 | 命名、注释、文档与风格细节 |
典型使用场景
- 只有半小时：先保证高风险路径被认真读完
- 涉及资金与权限：逐行核对边界条件与失败分支
- 影响面大但代码简单：重点确认调用方与回滚方式
- 剩余时间扫外围：存疑处标注问题，而不是直接放过
- 时间不够时明说：核心已看，其余约到明天继续
排序时先问三个问题
- 这次改动会影响资金、权限或数据正确性吗
- 出问题时能否快速回滚，回滚会丢掉什么
- 哪些部分是我最不熟悉、最容易看漏的
风险类型与审查深度
| 改动类型 | 审查深度 | 关注点 |
|---|---|---|
| 资金、计费、结算 | 逐行核对 | 精度、幂等、异常回滚 |
| 权限与鉴权 | 逐行核对 | 越权路径、默认值、缓存影响 |
| 公共接口变更 | 重点核对 | 兼容性、废弃策略、调用方迁移 |
| 命名与注释 | 快速扫读 | 与团队规范是否一致 |
按影响面切分阅读顺序
按影响面切分阅读顺序
# 先列出改动的文件与行数，再按风险排序
git diff --stat main...HEAD
git diff main...HEAD -- src/billing/ src/auth/ # 先读高风险路径
git diff main...HEAD -- tests/ docs/ # 再扫测试与文档评审不是限时抢答：没看完的改动宁可晚半天给结论，也不要给出虚假的批准。
时间不够就快速批准：最需要细看的高风险代码，往往就是这样被最先放过的。