EF Core中ICollection的Contains()无法翻译，List/IEnumerable却正常？

这个问题的核心在于EF Core的查询表达式翻译器对不同集合类型的处理逻辑差异，结合EF Core 3.0及以后严格的查询翻译规则（禁用隐式客户端求值），才会出现这个报错。

原因分析 #

EF Core在将LINQ表达式转化为SQL时，对于Contains方法的翻译有特定的类型识别逻辑：

• List：作为具体的集合实现类，EF Core明确知道如何将它的Contains方法映射为SQL的IN子句，直接把集合中的元素作为参数传入SQL查询。
• IEnumerable：作为LINQ的基础接口，EF Core的翻译器会优先尝试将其解析为可枚举的序列，进而转化为IN子句（只要序列能被提前枚举并获取元素）。
• ICollection：这个接口的问题在于，它本身只是定义了集合的基本操作（比如添加、删除、Contains），但EF Core的翻译器并没有内置对该接口Contains方法的直接支持。在EF Core 3.0之前（比如2.1），系统会 fallback 到客户端求值——也就是先把整个DbSet<Meter>的数据拉到本地，再用ICollection的Contains过滤，虽然不报错但性能极差；而3.0及以后默认禁用了隐式客户端求值，所以直接抛出翻译失败的异常。

解决方案 #

既然你的客户端方法大量使用ICollection<T>作为参数，有几种简单的解决办法：

1. 调用Search前将ICollection转为IEnumerable或List

这是最直接的方式，在构建查询前把集合转换为EF Core能识别的类型：

public void ClientMethod () {
    ICollection<int> ids = new List<int>() {1, 2, 3};
    // 转为IEnumerable
    var enumerableIds = ids.AsEnumerable();
    var results = _repository.Search(c=> enumerableIds.Contains(c.Id));
    // 或者转为List
    var listIds = ids.ToList();
    var results = _repository.Search(c=> listIds.Contains(c.Id));
}

2. 修改Repository方法，适配ICollection参数

可以给IRepository新增一个重载方法，专门处理基于ICollection的查询，在方法内部完成类型转换：

// 在IRepository中新增接口定义
List<Meter> SearchByCollection(ICollection<int> ids);

// 在Repository中实现
public List<Meter> SearchByCollection(ICollection<int> ids)
{
    var idList = ids.ToList();
    return _dbContext.Meters.Where(c => idList.Contains(c.Id)).ToList();
}

这样客户端可以直接传入ICollection参数，无需额外转换。

3. 表达式中显式转换（谨慎使用）

也可以在Lambda表达式里直接把ICollection转为IEnumerable，但需要确保EF Core能正确翻译：

public void ClientMethod () {
    ICollection<int> ids = new List<int>() {1, 2, 3};
    var results = _repository.Search(c=> ids.AsEnumerable().Contains(c.Id));
}

不过这种方式建议测试后再使用，避免某些场景下仍无法翻译。

额外说明 #

EF Core 3.0+的严格翻译规则是为了避免隐性的性能问题——之前2.1版本的客户端求值会导致全表扫描拉取数据，在数据量大时性能灾难。所以现在抛出异常是在提醒你：这个查询无法被转化为高效的SQL，需要你明确处理。

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