用证据说明评审发现

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

使用场景

评审教学profile读取路径：缓存未命中时getUser返回null，调用方随即读user.email。需要证明这条路径真实可达，不能只看到nullable就报缺陷。

具体做法

读取返回值定义、调用方和外围保护，记录具体输入/状态及版本。沿路径确定未命中是否能到达解引用，框架或类型是否已有处理；可运行时用未命中夹具复现，不能运行则标为代码推断。报告引用、触发、后果、已有保护为何不足及修复建议，按实际影响定级。无法确认则记录缺口而非确定缺陷。

反例

缺null检查违反最佳实践，必须加验证；不需要看调用方，严重程度定为最高。

改进写法

检查getUser未命中→profile读取email的实际路径。引用返回null与解引用位置，查外围是否提前退出；用未命中输入验证TypeError，或明确仅作静态判断。说明受影响入口和可行处理，不用规则名称代替故障证据。

为什么这样改

具体触发和传播路径解释为什么代码失败，也能排除已被上层保护的假阳性。影响与证据绑定，让作者可以复现而非争论抽象规范。

如何验证

教学无保护路径应可指出null进入解引用的两处引用；给调用方加明确未命中分支后，原发现不再成立。未运行样本只能称预期TypeError，不能伪造堆栈。干净路径允许零发现。

适用边界

动态生成字段不能靠文本缺失证明不存在。代码推断不等于现场故障；不可达触发或未知契约应说明。证据支持的信心仍不是校准概率，也不能因为评审必须“有价值”就制造问题。