代码评审四步法

第一步 · 意图

这次改动到底想解决什么？

先读 PR 描述、commit message 和 issue 链接，复述一遍你理解的意图；如果复述不出来，先把这个问题留给作者，再继续看代码。

第二步 · 实现

实现是否真的服务意图？

对照意图看 diff。先看新增/改动的入口，再看数据流。实现里若有看似无关的副作用，单独记下来，不要混进意见堆。

第三步 · 边界

空值 / 并发 / 失败 / 回滚 哪个会出问题？

为这四类各举一个例子问作者。如果作者能立刻回答，说明想清楚了；如果卡壳，那就是评审最有价值的产出。

第四步 · 可读性

六个月后还有人能看懂吗？

命名、注释、结构。只挑三个最影响理解的地方提建议，其他让作者自己定。少而具体的建议比一百条 nitpick 更容易被合并。