EF Core 8中静态集合/列表字段用于Contains()时查询无法翻译的原因咨询

Hey，针对你遇到的这些问题，我来给你拆解一下背后的核心原因，都是EF Core查询翻译机制里的细节逻辑：

1. 为什么静态readonly的ICollection<T>/IList<T>用在Contains()里无法翻译，去掉static就正常？ #

EF Core在翻译查询时，需要把代码里的表达式转化为对应的SQL，这其中关键是要能安全获取到用于生成IN子句的集合元素。

对于实例级的readonly集合字段，EF Core可以在查询准备阶段，从对应的实体实例中直接获取集合的实际值，然后把这些值嵌入到SQL的IN条件里——它能确定在当前查询周期内，这个实例字段的值是稳定的，不会被意外修改。

但静态readonly集合就不一样了：EF Core的表达式树分析器会认为，静态成员是全局共享的，哪怕标记了readonly，也存在被静态构造函数、反射或者其他线程篡改的可能。它没办法保证在查询准备和执行之间，这个静态集合的内容是完全不变的，所以不敢直接把它当作可安全嵌入的常量集合来生成SQL，只能尝试客户端求值；而EF Core 3+之后默认限制了客户端求值的场景，这就导致了“无法翻译查询”的错误。

2. 用IEnumerable<T>时没问题，是不是因为调用了不同的Contains()？ #

没错，这里确实是因为调用的是不同的方法，EF Core对它们的翻译逻辑完全不同：

• 当你用IEnumerable<T>的Contains()时，调用的是System.Linq.Enumerable.Contains()这个扩展方法。EF Core对这个方法的处理逻辑是，尝试枚举整个序列来提取所有元素，哪怕是静态的IEnumerable<T>，它会把这个序列当作一个可枚举的数据源来解析，进而生成对应的SQLIN条件。
• 而ICollection<T>/IList<T>的Contains()是它们的实例方法，EF Core在处理静态成员的实例方法调用时，没办法安全地获取到集合实例的具体值来转化为SQL，所以就无法完成翻译。

3. 为什么“静态”这个属性这么关键？ #

核心在于EF Core对静态成员和实例成员的“信任度”不同：

• 实例成员（哪怕是readonly）属于特定的对象实例，EF Core可以在查询执行时从当前上下文或实体实例中获取到确定的值，并且能保证在当前查询周期内这个值不会被修改。
• 静态成员是类级别的全局成员，不属于任何实例，EF Core无法确保它在查询的准备、执行过程中不会被其他线程修改——哪怕你标记了readonly，也存在被外部篡改的可能。为了避免生成的SQL和实际集合内容不一致（导致数据查询错误），EF Core不会冒险将静态集合直接翻译为SQL的IN子句，这就是静态属性导致问题的核心原因。

举个你提到的数据库模型示例：

public class Item
{
    public string Bar { get; set; }
    public string Foo { get; set; }
    // 其他属性...
}

备注：内容来源于stack exchange，提问作者Tim Lange