EF Core 9.0 中关于可空类型与合并运算符的查询异常分析

在 EF Core 9.0 版本中，开发人员报告了一个关于可空整型与合并运算符(??)在查询中使用的异常问题。这个问题在 EF Core 8.0 中表现正常，但在升级到 9.0 后会出现运行时异常。

问题现象

当开发人员尝试在 LINQ 查询中使用可空整型变量配合合并运算符时，EF Core 9.0 会抛出以下异常：

System.InvalidOperationException: 'The binary operator Equal is not defined for the types 'System.Int32' and 'System.Nullable`1[System.Int32]'.'

典型的问题查询示例如下：

int? test = 1;
var blog = db.Blogs
    .Where(b => b.BlogId == (test ?? 0)).ToList();

技术背景

这个问题涉及到 EF Core 查询转换过程中的几个关键技术点：

1. 表达式树转换：EF Core 需要将 LINQ 表达式转换为数据库查询语句
2. 可空类型处理：C# 中的可空值类型(Nullable<T>)在表达式树中有特殊处理
3. 合并运算符优化：EF Core 会对 ?? 运算符进行优化处理

问题根源

经过分析，问题的根本原因在于 EF Core 9.0 的表达式树优化器（funcletizer）在处理合并运算符时的类型转换不完整。具体来说：

1. 当 test ?? 0 中的 test 为非空时，优化器会直接将表达式替换为 test
2. 但合并运算符的结果类型应为非可空整型（因为右侧是 0）
3. 优化器在替换时没有添加必要的类型转换节点，导致后续表达式树中出现类型不匹配

影响范围

这个问题不仅影响简单的相等比较，还会影响以下场景：

1. 算术运算中的合并运算符使用
2. 包含方法调用（如 Contains）的查询
3. 各种二元运算符（如 >、<、+ 等）与合并运算符的组合

临时解决方案

在官方修复发布前，开发人员可以采用以下临时解决方案：

1. 显式类型转换：

.Where(b => b.BlogId == (int)(test ?? 0))

2. 使用条件表达式替代合并运算符：

.Where(b => b.BlogId == (test.HasValue ? test.Value : 0))

官方修复进展

EF Core 团队已经确认这是一个回归问题，并计划在 9.0.1 版本中修复。修复的核心思路是在优化合并运算符时，正确处理类型转换，确保表达式树中的类型一致性。

最佳实践建议

1. 在升级到 EF Core 9.0 时，应全面测试涉及可空类型与合并运算符的查询
2. 考虑在代码审查中加入对这类用法的检查
3. 对于复杂的查询表达式，可以考虑拆分为多个简单表达式，提高可读性和兼容性

这个问题提醒我们，在 ORM 框架中使用高级语言特性时，需要理解其底层转换机制，特别是在跨版本升级时，要关注可能的行为变化。