核心判断标准是数据是否仍在数据库中：IQueryable<T>用于数据库端查询（如分页、动态过滤），调用ToList等终结方法后转为IEnumerable<T>，否则EF Core无法翻译表达式树导致异常。
该用 IQueryable<T> 而非 IEnumerable<T> 的核心判断标准，就一条：数据是否还在数据库里没拉出来。 一旦调用了 .ToList()、.ToArray()、.AsEnumerable() 或完成遍历，后续所有查询操作就必须走 IEnumerable；否则 EF Core 会报 System.InvalidOperationException: The LINQ expression could not be translated——这不是语法错，是执行位置错了。
什么时候必须用 IQueryable<T> 做分页和过滤
数据库表有 50 万行，你要取第 1001–1020 条：IQueryable 生成的 SQL 是 SELECT ... OFFSET 1000 ROWS FETCH NEXT 20 ROWS ONLY（SQL Server）或 LIMIT 20 OFFSET 1000（PostgreSQL），只查 20 条；IEnumerable 会先把全部 50 万行加载进内存，再丢掉前 1000 条——GC 压力大，网络传输慢，可能直接 OOM。
-
IQueryable.Skip(1000).Take(20)→ 数据库端分页，安全 -
IEnumerable.ToList().Skip(1000).Take(20)→ 全量加载 + 内存分页，危险 - 动态拼接条件时（如搜索框多字段组合），
IQueryable支持链式.Where()累加表达式树，SQL 只含最终有效条件；IEnumerable每次.Where()都是在上一轮内存结果上再过滤，逻辑错且低效
IQueryable.Where 和 IEnumerable.Where 参数类型不同，不能混用
表面都是 .Where(x => x.Name.Contains("a"))，但底层签名完全不同：
-
IQueryable.Where接收Expression<Func<T, bool>>—— 编译器把它编译成表达式树，EF Core 才能尝试翻译成 SQL -
IEnumerable.Where接收Func<T, bool>—— 就是普通委托，运行时直接调用，无法翻译 - 常见翻车点：
DateTime.Now.AddDays(-7)在IQueryable中多数 Provider 不支持，必须提前算好值（var cutoff = DateTime.UtcNow.AddDays(-7);），或改用IQueryable.AsEnumerable().Where(...)（仅限小数据集）
误调 .AsEnumerable() 是最隐蔽的性能陷阱
.AsEnumerable() 不是“转个接口类型”那么简单，它会立即触发查询，把当前 IQueryable 表达式对应的所有数据一次性全拉到内存。之后哪怕只调一次 .First()，也已经晚了。
- 错误写法：
context.Orders.AsEnumerable().Where(x => x.Status == "Shipped").Take(10)→ 全表查出再内存过滤 - 正确写法：
context.Orders.Where(x => x.Status == "Shipped").Take(10)→ SQL 带 WHERE + TOP/LIMIT - 调试技巧：在 DbContext 配置中启用日志（
options.LogTo(Console.WriteLine)），看实际发出的 SQL 是否含预期条件；如果日志里只有SELECT * FROM Orders，说明你已经掉进IEnumerable陷阱了
真正容易被忽略的，不是“该用哪个接口”，而是「哪一行代码让 IQueryable 提前终结了」——.ToList()、.Count()、.Any()、.FirstOrDefault() 这些终结方法本身没问题，但一旦出现在链式查询中间，后面所有操作就都失效了。盯住调用栈里第一个终结操作的位置，比记住接口定义更重要。
