从netcore3.1迁移至net5.0后EF Core查询抛出SqlNullValueException异常

错误核心特征：调用栈显示Microsoft.Data.SqlClient.SqlBuffer.get_Int32()抛出异常，证明程序从数据库结果集读取int类型字段时实际取到了NULL值，且相同代码在.NET Core 3.1环境运行无异常。

为什么3.1正常、5.0才报错 #

两个核心差异直接导致了跨版本的行为不一致：

• EF Core 5对可空外键对应的可选导航属性，做了无意义的查询优化：会把关联表的int类型主键列投影到结果集，哪怕此时外键本身是NULL值、根本不需要构建关联导航对象。当左连接匹配不到关联行时，关联表的主键列会返回NULL，新版本直接尝试读取该列的int值，就会触发空值异常。
• 旧版本的查询管道遇到外键为NULL的场景，会直接跳过关联表的列读取，不会把无匹配的关联列纳入结果集，因此不会触发空值读取逻辑。

精准排查步骤 #

• 先缩小排查范围：因为抛错的是get_Int32()方法，不需要排查string、decimal等其他类型的列，直接把范围锁定到所有int类型字段，包括非空外键UpdatedBy、ClinicId，可空外键ServiceGroupId、IndustryCodeId，以及关联表自身的主键Id列。
• 验证可空外键场景：从实体定义看，ServiceGroupId和IndustryCodeId是可空int类型，对应的导航属性是可选关系。只要数据库里存在这两个字段为NULL的记录，新版本的查询逻辑就会触发空值读取。
• 检查代码层面的配置偏差：当前实体属性块中#nullable enable的位置在属性列表中间，会导致两个问题：
  • 指令之前的所有属性都处于可空引用类型禁用上下文，EF会把这些引用类型的属性默认判定为可空导航，进一步扩大左连接的查询范围；
  • 指令之后的导航属性被纳入可空启用上下文，EF会根据属性的可空标注判断关系类型，和旧版本的判定逻辑产生偏差。
• 抓取实际生成的SQL：开启EF Core的SQL日志输出，查看左连接片段，确认是否存在无意义投影关联表int主键列的情况。

可落地的修复方案 #

• 修正可空上下文的配置：把#nullable enable指令移到整个实体类定义的最开头，统一可空上下文的作用范围，避免EF对导航属性的可空性做出误判。
• 显式标注关系可空性：对可空外键对应的导航属性，在模型配置中显式标记为可选关系，避免EF生成非预期的列投影，示例配置如下：

  modelBuilder.Entity<Item>()
    .HasOne(item => item.ServiceGroup)
    .WithMany()
    .HasForeignKey(item => item.ServiceGroupId)
    .IsRequired(false);
  

• 版本适配：如果是EF Core 5初期版本的已知查询优化bug，可以升级到5.0.10及以上的修复版本，解决查询管道无意义投影关联列的问题；临时规避也可以降级到稳定的EF Core 3.1版本。
• 数据层校验：检查所有外键关联的完整性，补全缺失的关联行，或者清理无效的外键值，从数据层面消除左连接返回空int列的场景。

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