Enumerable Intersect与Any表达式无法编译为SQL？EF Core IQueryable开发问题

1. 复现用的简化查询本身存在语法缺陷 #

你写的用于复现问题的最小查询首先存在硬伤：括号完全不闭合。Intersect是带两个参数的方法，你目前的代码只写了开括号，把常量列表包进去之后就直接链上了.Any()，相当于把残缺的方法调用传给了Where。编译器只是刚好匹配上了外层的括号嵌套才没报语法错，到了EF Core解析阶段，残缺的方法调用会传递null参数，最终在内部构造表达式树的时候，触发Expression.Lambda的空值异常。

就算你补全所有括号，老老实实写成e.AccessList.Select(x => x.Id).Intersect(new List<int>(){90,91,92}).Any()，这个查询也大概率跑不通。EF Core本身对导航集合.Intersect(内存常量集合)这类跨库内存的Intersect操作的翻译逻辑存在已知缺口：它不会把这个逻辑优化成更合理的"存在交集"判断，反而会尝试把整个逻辑映射成SQL原生的INTERSECT集合操作，要求两侧的数据源都具备完整的数据库查询元数据。遇到内存里的常量列表时，翻译流程直接中断，轻则抛出"无法转换为SQL"的错误，重则像你遇到的那样触发内部空引用。

2. 手写表达式树的实现不兼容EF Core翻译规则 #

你手写构造的那段表达式树，本身就没满足EF Core的翻译要求：

• 你把常量列表用AsEnumerable()转成了内存对象，相当于把本来可以被EF Core识别为SQL参数的集合，变成了没有查询元数据的内存对象，翻译流程走到Intersect节点的时候，根本拿不到两侧的查询源信息，只能直接抛出转换失败的错误。
• 你构造的逻辑本质上是"先把常量列表和实体属性的id列表做全量交集，再判断交集是不是非空"，这个两步的逻辑太复杂了，EF Core的翻译器不会把它优化成一步的存在性判断，只要逻辑链路稍微复杂一点，就会触发兜底的拒绝转换逻辑。

你要实现的"两个列表只要存在一个相同条目就返回true"的逻辑，根本不需要依赖Intersect。等价的写法是"实体关联的id列表中，任意一个id出现在允许常量列表中就算匹配"，也就是用Any加Contains的组合——这是EF Core全版本稳定支持的写法，会自动翻译成最高效的EXISTS子查询，没有任何兼容问题。

改造后的扩展方法代码：

public static IQueryable<T> AuthorizedRecords<T>(this IQueryable<T> query, Expression<Func<T, IEnumerable<int>>> employeeIdsSelector)
{
    // 替换为实际的常量允许列表
    var allowedIds = new List<int> { 1, 2, 3 };
    
    // 构造判断逻辑：集合中的每个id 只要在允许列表里就算匹配
    var idParam = Expression.Parameter(typeof(int), "id");
    var containsMethod = typeof(List<int>)
        .GetMethod(nameof(List<int>.Contains), new[] { typeof(int) })!;
    var containsCall = Expression.Call(
        Expression.Constant(allowedIds),
        containsMethod,
        idParam
    );
    var anyElementPredicate = Expression.Lambda<Func<int, bool>>(containsCall, idParam);
    
    // 获取 Enumerable.Any 的重载：接收集合 + 条件判断
    var anyMethod = typeof(Enumerable)
        .GetMethods()
        .First(m => m.Name == nameof(Enumerable.Any) 
                    && m.GetParameters().Length == 2)
        .MakeGenericMethod(typeof(int));
    
    // 组合最终的Where条件：e => e对应的id集合.Any(id => allowedIds.Contains(id))
    var selectorBody = employeeIdsSelector.Body;
    var finalWhereCall = Expression.Call(anyMethod, selectorBody, anyElementPredicate);
    var finalWhereLambda = Expression.Lambda<Func<T, bool>>(finalWhereCall, employeeIdsSelector.Parameters);
    
    return query.Where(finalWhereLambda);
}

对应的简化查询，替换为兼容写法即可正常运行：

dbContext.Meetings
  .Where(e => e.AccessList
    .Select(x => x.Id)
    .Any(id => new List<int> { 90, 91, 92 }.Contains(id))
  );

• 这种写法最终生成的SQL和你原本想用Intersect().Any()实现的逻辑完全等价，性能反而更好：不需要做全量的集合对比，直接通过EXISTS做关联匹配，没有多余的集合遍历开销。
• 不要给常量列表套AsEnumerable()，不然会把本来可以下推到SQL的查询直接拉到客户端执行，带来不必要的性能损耗。

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