读 diff 的两种模式
读 diff 有两条路：按文件顺序线性通读，或按意图切片读——先确认核心实现，再看测试，最后看配置与文档。改动越大越需要先建立全貌：先看文件统计与目录分布，再挑关键路径精读，否则注意力会在后半段枯竭，真正危险的地方反而没人细看。
基本信息
| 适用平台 | GitHub PR / GitLab MR / Gerrit Change 的差异视图 |
|---|---|
| 前置输入 | PR 描述与提交信息：先拿到意图，再读代码 |
| 推荐顺序 | 核心逻辑 → 测试 → 配置与文档 |
| 大改动的做法 | 先看 --stat 统计与目录分布，再逐块精读 |
典型使用场景
- 数百行的重构：先读描述确认行为不变，再逐块核对等价性
- 混合型改动：实现、测试、文档挤在一个 PR 里，按类型分组读
- 陌生模块：先读调用方再回到实现，避免只有局部视角
- 纯配置改动：对照默认值与环境差异，确认影响范围
- 抓不到重点时：先读测试，从断言反推预期行为
线性通读与切片阅读
| 场景 | 线性通读的问题 | 切片阅读的做法 |
|---|---|---|
| 数百行以上的改动 | 读到后段注意力衰减，高风险代码没被细看 | 先按目录分类，核心路径与数据路径优先精读 |
| 夹带大量重命名 | 噪声淹没真实的逻辑变更 | 用忽略空白与识别重命名的视图，只读逻辑文件 |
| 跨多个模块 | 上下文频繁切换，只看到局部 | 每个模块单独一轮，读完写下该模块的结论 |
先看全貌再精读
先看全貌再精读
git diff main...HEAD --stat # 先看文件与行数分布
git diff main...HEAD -- src/order/ # 只看核心目录
git diff -w main...HEAD # 忽略纯空白改动
git diff main...HEAD -M --stat # 识别重命名，而不是删除加新增
git log --oneline -5 # 回顾作者的提交拆分意图读不懂时直接提问：把猜测写进评审结论，等于把不确定性一并传递给了主干代码。
读后自检：合上页面能否复述改动做了什么、影响哪些行为；说不清说明还没读透，继续读或把疑问标出来。