Honesty 
Typecho 前言：Code Review 的残酷现实
理想中的 Code Review 是这样的：
现实中的 Code Review 是这样的：
本文就是为第二种场景服务的——当你实在没时间、没精力、没背景知识看懂一个 PR 的时候，如何在不暴露自己的前提下，给出一个看起来很专业的 Review。
第一章：Reviewer 画像分类
在学习话术之前，先了解 Code Review 中各种 Reviewer 的生存形态：
我们今天重点培养的是装懂高手的能力——看得不多，但说得有分量。
第二章：进入 PR 前的准备工作
不打无准备之仗。打开 PR 之前，先做三件事：
2.1 读 PR 标题和描述（必做，耗时 30 秒）
这是你唯一需要认真读的部分。PR 描述里通常包含：
- 做了什么：给你提供评论的弹药
- 为什么这样做：给你提供质疑的切入点
- 测试了什么：给你提供追问的方向
如果 PR 没有描述，恭喜你，你拥有了第一条评论的素材：
「能否补充一下这个 PR 的背景和改动原因？方便 Review」
这条评论专业、合理、无懈可击，而且能为你争取到额外的理解时间。
2.2 看 Diff 的数字（必做，耗时 10 秒）
2.3 看改动了哪些文件（必做，耗时 20 秒）
文件名能告诉你这个 PR 的性质：
| 文件特征 | 含义 | 你的策略 |
|---|---|---|
只改了 *Test.java | 纯测试改动 | 问覆盖率，稳赚不赔 |
改了 *Controller.java | 接口层改动 | 问入参校验和响应码 |
改了 *Repository.java | 数据层改动 | 问索引和 N+1 问题 |
改了 *Config.java | 配置改动 | 问各环境是否同步 |
改了 pom.xml | 依赖升级 | 问是否测试过兼容性 |
| 改了几十个文件 | 重构或格式化 | 问有没有功能性改动混进来 |
第三章：万能评论话术库
这是本文的核心章节。以下话术经过真实 Code Review 场景验证，覆盖率达到 95% 以上的场景。
3.1 开场白类——让人觉得你认真看了
话术 A：整体肯定型
「整体看下来思路很清晰，几个小点想确认一下。」
效果：暗示你看完了全部代码，同时为后续问题铺垫。
话术 B：背景确认型
「想先确认一下理解是否正确：这个改动主要是为了解决 XX 问题，对吗？」
效果：即使你没看懂，也显得你在思考业务逻辑。如果理解错了，作者会纠正你，你反而能借此真正理解 PR 的目的。
话术 C：点赞占位型
「这个设计思路不错，之前类似场景我们都没处理这么优雅。」
效果：作者立刻对你有好感，后续即使你提不出什么实质意见，这个 PR 大概率也能顺利 Approve。
3.2 专业质疑类——让人觉得你很懂
话术 D：边界条件万能问
「这里如果入参为 null 或者空集合，会怎么处理？」
适用场景：任何有参数的方法。成功率 100%，因为总会有某个地方没考虑边界。
话术 E：并发安全万能问
「这个方法在高并发场景下是线程安全的吗？」
适用场景：任何 Service 层代码。即使方法本身是无状态的，作者也得解释一番，你就赢了。
话术 F：性能担忧万能问
「数据量大的时候这里的性能怎么样，有没有考虑过分页或者缓存？」
适用场景：任何涉及数据库查询或集合遍历的代码。
话术 G：异常处理万能问
「这里如果下游接口超时或者返回异常，上层会怎么处理？」
适用场景：任何有外部调用的地方。支付系统尤其好用。
话术 H：测试覆盖万能问
「这块逻辑有对应的单元测试吗？特别是异常分支。」
适用场景：任何你看不懂的代码。不管有没有测试，这个问题都成立。
3.3 看起来读懂了类——最高段位话术
高级话术的关键是关联到系统全局，显示你不只是在看这一个 PR，而是在思考整个系统。
3.4 Nit 评论类——小改动显示认真
「Nit」是 Code Review 中的高频词，意思是「小挑剔，可改可不改」，英文全称 Nitpick。妙处在于：
- 提了意见，显得认真
- 说了是 Nit，对方可以不改
- 两边都不得罪
- 实际上你什么都没看懂
Nit: 这里的变量名 `data` 可以改成 `accountList` 更语义化，不改也行。
Nit: 这个方法有点长了，以后有机会可以考虑拆一下，不影响这次合并。
Nit: 注释里有个错别字，`帐户` 建议改成 `账户`。（错别字类 Nit 是最安全的，跟代码逻辑完全无关）第四章：各种棘手场景的应对策略
4.1 场景一：代码涉及你完全不懂的领域
比如密码学、复杂算法、你从来没接触过的业务模块：
4.2 场景二：PR 改动了 800 行，你只有 5 分钟
这是最常见的困境。解决方案：战略性精读。
第 1 分钟：读 PR 描述，搞清楚「改了什么」
第 2 分钟：看文件列表，找最核心的那 1-2 个文件
第 3 分钟：只看核心文件的入口方法和主逻辑
第 4 分钟：翻一下测试文件，看测试了什么场景
第 5 分钟：写评论5 分钟后你能给出的评论：
「核心逻辑看起来没问题，主要改动集中在
TransferService的process方法，逻辑比之前清晰多了。几个小点：
processInternal方法的异常有没有统一处理？- 测试里好像没有覆盖金额为零的边界场景？
其他改动主要是重构，LGTM。」
对方看到这条评论会觉得：这哥们认真看过核心逻辑，而且提了有价值的问题。
4.3 场景三：你 Approve 了，结果出 bug 了
这是最需要话术的场景：
人生建议：R1 是最好的选择。承认自己没看到，然后说下次会怎么做。这比任何防御性话术都更赢得信任，而且不会让人觉得你在甩锅。
4.4 场景四：作者追问你某个技术细节
作者：你觉得这里用 CompletableFuture 还是用 reactive stream 更合适？
你（内心）：我不知道这两个有什么区别。
你（嘴上）：?正确应对：
方案 A（最推荐）：「这个要看你们的具体场景，如果整体技术栈已经是响应式的，统一用 reactive 更好；如果只是这一处异步，CompletableFuture 更轻量。你们当前栈是什么？」
把问题还给对方，显得你在做权衡，而不是不知道答案。
方案 B：「我觉得都行，你对这个更熟，你定吧，我更关注接口的行为是否正确。」
优雅放弃技术判断，把自己定位成业务正确性的把关人。
第五章：不同类型 PR 的专属话术
5.1 Bug Fix PR
✅ 专业开场：
「能否在描述里补充一下这个 Bug 的复现步骤？方便以后排查类似问题。」
✅ 核心追问：
「这个 Fix 有没有对应的回归测试？防止以后又被改回去。」
✅ 延伸关联：
「同样的逻辑在 XX 地方也有类似代码，要不要一起看看？」5.2 新功能 PR
✅ 专业开场：
「这个功能的设计文档或者技术方案有吗？想对齐一下实现和设计的一致性。」
✅ 核心追问：
「异常情况下用户看到的是什么？前端有没有对应的错误处理？」
✅ 延伸关联：
「这个功能上线后怎么验证效果？有没有埋点或者监控指标？」5.3 重构 PR
✅ 专业开场：
「重构前后行为完全一致吗？有没有哪些边界 case 在重构过程中可能被改变了？」
✅ 核心追问：
「测试覆盖率有没有变化？重构后的测试和重构前相比是增加了还是减少了？」
✅ 最安全的评论：
「这个重构让代码清晰多了，特别是 XX 部分。」
（XX 部分填你唯一看懂的那个方法名）5.4 依赖升级 PR
✅ 没有任何背景知识也能问的问题：
「这个版本的 Release Notes 有没有 Breaking Changes？」
「CI 上所有测试都过了吗？」
「各个环境都验证过了吗？还是只在开发环境测了？」
「有没有影响到其他依赖这个包的模块？」依赖升级 PR 是最适合「装懂」的场景，因为所有问题都是合理的，没人能说你没在认真看。
第六章：Code Review 的段位体系
本文教的是从青铜升到黄金/铂金的过渡期生存技能。
真正的目标是王者，但那需要的不是话术，而是时间和经验的积累。话术只是过渡期的拐杖，不是终点。
第七章：你不该假装看懂的情况
前面说了这么多「如何装」，最后必须说清楚什么时候不能装：
这不是在开玩笑。支付系统的一个漏洞，轻则线上故障，重则资金损失。在核心路径上假装看懂了，后果是实实在在要承担的。
第八章：如何成为一个真正好的 Reviewer
既然写了这么多「装懂」的技巧，也应该说说真正好的 Code Review 长什么样：
最好的 Reviewer 不是那个每次能找出最多问题的人，而是那个让作者在 Review 过程中成长的人。
结语：装懂是手段，看懂才是目的
Code Review 的话术，本质上是一种学习型假装——你用这些问题去探测代码的边界，在作者的回答里真正理解设计意图。每一个「边界场景怎么处理」的问题，背后都是你在建立自己的知识体系。
假装看懂是起点，不是终点。
如果三年后你还在用本文的话术，而没有进化成真正能看懂的那个人——那才是真正的放弃。