EF Core 9.0 中 ImmutableArray.Contains 方法的查询转换问题解析

问题背景

在 EF Core 9.0 版本中，开发者报告了一个关于集合查询的回归问题。当使用 ImmutableArray<T> 的 Contains 方法进行 LINQ 查询时，EF Core 9.0 会抛出异常，而在 8.0.1 版本中同样的代码却能正常工作。这个问题不仅限于 SQLite 提供程序，而是影响所有数据库提供程序。

问题表现

典型的错误场景如下：

var dbKeys = dbTags.Select(t => t.Value).Distinct().ToImmutableArray();

var existingEntities = await context
    .Tags.Where(t => dbKeys.Contains(t.Value))
    .ToArrayAsync(cancellationToken);

上述代码在 EF Core 9.0 中会抛出 ArgumentException，提示无法将 ImmutableArray<string> 类型用于 IEnumerable<string> 参数。

问题根源

这个问题源于 EF Core 9.0 对查询方法转换逻辑的修改。EF Core 在将 LINQ 表达式转换为 SQL 查询时，需要识别并转换 Contains 方法调用。在 9.0 版本中，查询转换器对集合类型的处理逻辑发生了变化：

1. 对于实现了 ICollection<T> 接口的类型，EF Core 会假设其 Contains 方法就是查询所需的包含方法
2. 对于泛型集合类型，EF Core 假设第一个泛型参数是元素类型
3. ImmutableArray<T> 虽然实现了 IEnumerable<T>，但其转换路径与普通数组不同

解决方案与变通方法

目前有以下几种解决方案：

1. 使用普通数组替代 ImmutableArray：

   var dbKeys = dbTags.Select(t => t.Value).Distinct().ToArray();
   

2. 显式转换为 IEnumerable：

   var existingEntities = await context
       .Tags.Where(t => dbKeys.AsEnumerable().Contains(t.Value))
       .ToArrayAsync(cancellationToken);
   

3. 对于自定义集合类型：

   • 确保实现 ICollection<T> 接口
   • 如果使用泛型集合，确保第一个泛型参数是元素类型
   • 避免在集合类型中使用非标准的泛型参数顺序

技术细节分析

EF Core 9.0 在查询转换过程中，对 Contains 方法的处理变得更加严格。当遇到集合类型时：

1. 首先检查方法是否来自 IQueryable<T> 或相关接口
2. 对于实现了 ICollection<T> 的类型，会特殊处理其 Contains 方法
3. 对于泛型集合，假设第一个泛型参数是元素类型

这种变化导致了一些之前能工作的场景现在会失败，特别是对于像 ImmutableArray<T> 这样不常见但标准的集合类型。

最佳实践建议

1. 在 EF Core 查询中优先使用标准集合类型（如 List<T>、T[]）
2. 如果必须使用特殊集合类型，考虑在查询前转换为标准集合
3. 对于复杂的自定义集合类型，可能需要实现自定义查询转换器
4. 测试覆盖所有使用集合的查询场景，特别是在升级 EF Core 版本时

总结

EF Core 9.0 对集合查询的处理逻辑进行了优化，这虽然提高了大多数场景的性能，但也带来了一些兼容性问题。开发者需要了解这些变化，并在代码中做出相应调整。微软团队已经确认这是一个回归问题，可能会在未来的版本中修复。在此期间，使用上述变通方法可以解决大部分相关问题。