C#条件运算符在EF查询中两侧求值引发空引用异常 咨询原因及方案

你遇到的空引用异常核心源于EF查询的执行逻辑和普通C#代码的本质差异：
写在EF Where 中的Lambda不会被编译成可直接执行的托管IL，而是会被编译器生成表达式树（Expression Tree）——这是一种用来描述代码逻辑的结构化数据，EF的查询提供器会遍历整棵树的所有节点，把逻辑翻译成数据库可执行的SQL语句。

C#中?:条件运算符的短路求值规则，仅在代码作为普通本地逻辑执行时生效。在表达式树场景下，EF遍历节点时不会执行C#层面的分支判断，会无差别访问所有子表达式节点来完成SQL拼接、参数计算：

• 你代码里的w是被Lambda闭包捕获的本地变量，不属于数据库映射字段。EF在准备SQL参数时，碰到w.EquipmentTypeInfo.Identity.EntityKey这个成员访问节点，会直接尝试读取属性值，根本不会先执行w.EquipmentTypeInfo == null的判断再决定是否访问后续属性。
• 哪怕你把null判断写在?:分支里，只要对应子表达式存在于表达式树中，EF遍历到就会触发本地属性访问，w.EquipmentTypeInfo为null时自然会抛出空引用。

你把逻辑挪到EF查询外部能正常运行，本质是这部分代码作为普通C#逻辑执行时，编译器会正确生成短路求值的IL，自然不会访问null对象的属性。

触发异常的代码如下：

var equipment = context.Equipments.Where(d =>
       d.RouteEquipmentInfoType == w.RouteEquipmentInfoType
    && d.EquipmentTypeInfoEntityKey == (w.EquipmentTypeInfo == null ? null : w.EquipmentTypeInfo.Identity.EntityKey)).FirstOrDefault();

根据null对象的类型，对应处理方案如下：

• 处理闭包捕获的本地变量（比如示例中的w）
  最稳妥、性能最高的方式是在传入EF查询前，提前在外部完成所有null判断和值计算，不要把本地对象的null判断逻辑放进表达式树，从根源上避免EF遍历表达式时触发意外属性访问：

  // 查询外部执行普通C#逻辑，空传播、条件运算符都可正常短路
  var targetEntityKey = w.EquipmentTypeInfo?.Identity.EntityKey;
  var equipment = context.Equipments.Where(d =>
         d.RouteEquipmentInfoType == w.RouteEquipmentInfoType
      && d.EquipmentTypeInfoEntityKey == targetEntityKey).FirstOrDefault();
  

• 处理数据库实体的导航属性（关联表数据可能为null的场景）
  不要自定义嵌套?:判断，直接使用EF原生支持的null比较逻辑即可：
  • EF Core原生支持C#空条件运算符?.，会自动翻译成SQL对应的LEFT JOIN + IS NULL判断，不会触发客户端空引用
  • 旧版本EF/EF6中，直接拆分条件用&&/||连接即可，EF查询翻译器会自动识别null语义，生成正确SQL，不会触发本地求值空引用：

    // 导航属性null判断示例
    var data = context.Equipments.Where(d => 
        d.EquipmentTypeInfo == null || d.EquipmentTypeInfo.Status == 1).ToList();
    

注意不要为了绕开问题强行开启EF客户端求值，该行为会加载全表数据到内存，性能损耗极大。

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