代码审查的第一步，是确认PR描述及关联Issue的有效性。不要急于逐行阅读代码，先打开Description区域——如果没有清晰的变更说明，必须暂停审查并要求补充，否则你无法判断这段逻辑是修复Bug、新增功能还是偿还技术债，后续意见很容易偏离方向。接着检查关联的Issue编号是否真实存在且状态为Open或In Progress；如果链接失效或Issue已关闭，直接在评论区标注“请核实需求上下文”。

团队协作中，最忌讳给出“写得不错”或“建议优化”这类笼统评价。真正有效的审查意见，应当让开发者一眼看清问题所在、为什么重要以及如何改进。那么，应该从何入手？

明确审查目标与范围

打开PR页面时，先别急于查看代码——点击Description区域，确认本次提交是否附带了清晰的变更说明；如果没有，必须暂停审查，退回给提交人补充。缺乏上下文，你难以判断这段逻辑是修Bug、加功能还是清理技术债，后续所有意见都可能偏离重点。接着检查关联的Issue编号是否真实存在且状态为Open或In Progress；若链接失效或Issue已关闭，直接在评论区标注“请核实需求上下文”。

聚焦四类高危问题逐项扫描

方法一：可运行性验证
在本地checkout该分支，然后运行make test或npm test（根据项目实际命令），观察是否全部通过。若有任一测试失败，立即标记为Blocker级别问题，无需进入下一轮检查。

方法二：空值与边界防御
搜索新增代码中所有.get()、.find()、[index]、response.data字段访问操作，在其前一行插入断点式注释：// TODO: check null/undefined，要求开发者显式处理或添加断言。任何遗漏都可能导致上线后触发TypeError。

方法三：敏感信息硬编码
全局搜索'password'、'key'、'secret'、'token'字符串，若出现在.js/.py/.go源码中（非test文件或.env.example），一律标记为严重问题。严禁在代码中硬编码凭证，必须使用环境变量或密钥管理服务。

结构与可维护性判断

第一步：定位新增函数或类，使用编辑器的折叠功能收起所有内部实现，仅查看函数签名和注释。
第二步：检查参数数量是否不超过3个；若超过，则提示“建议拆分为多个小函数或封装为配置对象”。
第三步：查看是否存在超过15行未折叠的连续逻辑块；若有，直接引用《Clean Code》第3章原文：“函数应该只做一件事”，并建议提取为独立函数，命名需体现意图（如calculateTaxAmount而非processStep2）。