代码审查只看 PR Diff 有什么不足，如何补充审查上下文？

核心回答

PR Diff 只显示改了哪些行，不能完整展示这些行依赖的调用方、数据约束和运行环境。只看差异，可能漏掉未修改代码中的前置条件、下游副作用、权限检查或兼容性要求。应从需求出发，沿受影响行为补读必要上下文，再用测试或具体执行路径支持判断。

按影响链补上下文

• 入口与调用者：谁传入参数，哪些校验已经做过，是否还有其他调用方依赖旧行为。
• 被调用实现与数据：方法真实的事务、异常、缓存和外部请求语义；字段能否为空，唯一约束和状态转换如何约定。
• 接口与配置：返回结构、序列化、权限范围、功能开关、运行版本与部署配置。
• 测试与设计依据：已有测试在保护什么，新的需求为何要改，注释和设计约束是否仍成立。

例如一个方法把“查不到返回空集合”改成返回 null，差异可能只有一行，但未改的调用者直接遍历结果就会失败。只检查新方法自身的分支，无法判断整个调用链是否仍然正确。

范围怎样控制

从变更符号查引用，读取相关函数及必要的上下游，不必为了一个局部修改通读整个仓库。找不到契约时先指出缺失的信息，不根据函数名推断行为。让 AI 协助检索和归纳时，也要检查它实际读到了哪些文件；提供仓库规则和路径规范有帮助，但工具拿到更多上下文不等于判断必然正确。

有效的审查意见应说明触发条件、相关位置和结果，必要时补最小复现。对尚未证实的疑点，可以说明待确认条件，不把它直接写成确定漏洞。

对应教程

参考资料