默认只评审 diff，明确风险时例外

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

一个补丁把函数F的锁获取顺序改为A后B。已有调用方可能先持B再调用F，因此仅看diff不足；但也无需无目的通读仓库。

具体做法

固定基线和目标树，先读diff及直接上下文。命名风险“调用方持B进入F获取A可能与另一A→B路径形成环”，据此检查相关调用方和锁释放/等待条件。记录扩展文件和结果；出现新具体风险再有界扩展。报告未覆盖动态调用，不能用检查范围小推无全局风险。

反例

要么扫描所有代码找任意问题，要么禁止读diff外内容，忽略调用方锁状态。

改进写法

从F改动diff开始，以锁顺序环为具名风险检查持B调用方和A→B路径。列实际检查文件、持锁条件和可能后果；排除不可重叠路径，动态调用未检查明确记录。每次扩展都有对应风险。

为什么这样改

diff确定审查焦点，具名例外允许查到故障成立所需上下文。这样避免窄到错过调用约束，也防止无关历史问题淹没本次变化。

如何验证

教学调用方G持B再调用F，与并发H持A等B构成候选死锁环；还需核对是否可同时运行及释放条件。若G进入F前释放B，原风险被排除。扩展记录应能关联这项判据。

适用边界

横切API、共享状态或生成代码可能需更广检查，范围应跟风险调整。静态路径不代表实际并发已发生；只报告推断或复现所支持的结论。已有审查范围约束仍须遵守。