ReSharper空值分析疑问：无法判定非空及空引用警告原因

咱们先聚焦你提到的第二个问题——为啥ReSharper会在else分支里警告File2可能为空？明明file2Data非空的话，File2当时肯定不为空啊。

原因解析 #

问题出在两个关键点上：

1. ?.操作符的反向推断局限：ReSharper的空值分析默认不会反向推导依赖关系。当你用File2?.Data得到file2Data时，它能知道file2Data == null意味着File2为空或者Data为空，但反过来，它不会主动推断file2Data != null就一定代表File2不为空。
2. 公共字段的线程安全隐患：你的File2是一个public字段，ReSharper会考虑到其他线程可能在File2?.Data执行之后、else分支执行之前，把File2修改为空的情况。对于这类可被外部修改的成员，它不会做“非空”的强推断。

解决办法 #

最稳妥的方式是把File2的引用捕获到局部变量里——局部变量在当前线程内不会被外部代码修改，ReSharper能准确跟踪它的非空状态：

var localFile2 = File2;
var file2Data = localFile2?.Data;
if (file2Data == null) {
    CanSaveFile2 = false;
} else {
    // 这里不会再出现空引用警告
    CanSaveFile2 = localFile2.FileOpen;
}

如果你100%确认File2不会在这段代码中被修改，也可以用空值断言!来压制警告，但这种方式风险较高，不推荐在不确定的场景使用：

CanSaveFile2 = File2!.FileOpen;

再来说第一个问题：为啥ReSharper空值分析无法判定某对象不可能为空？ #

这通常是以下几种情况导致的：

• 对象是可外部修改的成员：比如public字段、未做线程安全保护的属性，ReSharper无法保证它在代码执行路径中不会被其他线程或外部代码改为null。
• 缺乏空值特性标注：如果你的代码没有使用JetBrains的[NotNull]/[CanBeNull]特性，或者.NET的Nullable Reference Types（NRT），ReSharper的分析精度会大打折扣——它没法明确知道某个成员的空值预期。
• 复杂控制流或未分析的方法调用：如果对象的非空性依赖于多层嵌套的条件判断，或者调用了没有标注空值信息的外部方法，ReSharper无法深入分析这些逻辑，也就没法确定对象一定非空。
• 反向推导的局限性：就像第二个问题里的场景，ReSharper不会总是做反向逻辑推导，比如从a?.b != null推导出a != null，尤其是当a是可变成员时。

内容的提问来源于stack exchange，提问作者rollsch