该用 IEnumerable 而非 IQueryable 的核心判断标准是数据是否已加载到内存：若查询未执行、仍在构建 SQL（如 DbSet），应使用 IQueryable；一旦调用 .ToList()、.ToArray() 或遍历完成，后续操作必须用 IEnumerable，否则会因无法翻译为 SQL 而抛出异常。
什么时候该用 IEnumerable<t></t>，而不是 IQueryable<t></t>
核心判断标准：数据是否已经从数据库拉到内存里。如果查询还没执行、还在拼接 SQL（比如 Entity Framework 的 DbSet<t></t>），就该用 IQueryable<t></t>；一旦调用了 .ToList()、.ToArray() 或遍历完成，后续操作必须用 IEnumerable<t></t>，否则会触发“无法翻译成 SQL”的异常。
常见错误现象：System.InvalidOperationException: The LINQ expression could not be translated —— 通常是你在 IQueryable 上调用了 EF 不认识的方法（比如自定义函数、string.Contains 在某些旧版 Provider 中不支持、或用了 DateTime.Now 而不是 DateTime.UtcNow）。
-
IQueryable是“可组合的查询表达式树”，延迟执行，SQL 由 Provider 翻译生成 -
IEnumerable是“内存中集合的迭代器”，立即执行（调用时才真正计算），所有操作走 .NET 运行时逻辑 - 把
IQueryable强转成IEnumerable（如.AsEnumerable()）会提前把全部数据拉进内存，之后的.Where、.Select都在本地执行 —— 数据量大时极危险
IQueryable.Where 和 IEnumerable.Where 行为差异极大
表面上都是过滤，但底层完全不是一回事：IQueryable.Where 接收的是 Expression<func bool>></func>，编译器把它构造成表达式树供 EF 解析；IEnumerable.Where 接收的是 Func<t bool></t>，是直接可执行的委托。
这意味着你不能在 IQueryable 上写这种代码：
var now = DateTime.Now; var result = context.Orders.Where(x => x.CreatedAt > now.AddDays(-7)); // ❌ 大部分 EF Provider 不支持 AddDays
正确写法是用可翻译的等价形式，或提前算好值：
- ✅ 改用
DateTime.UtcNow.AddDays(-7)（EF Core 5+ 支持部分DateTime方法） - ✅ 提前计算：
var cutoff = DateTime.UtcNow.AddDays(-7); ... Where(x => x.CreatedAt > cutoff) - ✅ 必须用复杂逻辑时，先
.AsEnumerable()再.Where，但只适用于小数据集
分页场景下 Skip/Take 必须用 IQueryable
IEnumerable.Skip(n).Take(m) 会先把整个集合枚举出来，再丢弃前 n 项 —— 如果表有百万行，.Skip(10000).Take(20) 会加载全部 10000+ 行到内存，再扔掉 9980 个。
而 IQueryable.Skip(n).Take(m) 会被翻译成 OFFSET n ROWS FETCH NEXT m ROWS ONLY（SQL Server）或等效的 LIMIT/OFFSET（PostgreSQL/MySQL），只取需要的 20 行。
- EF Core 5+ 默认启用
Microsoft.EntityFrameworkCore.Query的分页警告：若检测到IEnumerable分页，会抛InvalidOperationException - Web API 分页接口中，务必保持返回类型是
IQueryable<t></t>直到最后一步（如.ToListAsync()），中间不要穿插.ToList() - DTO 映射也建议在
IQueryable阶段做：query.Select(x => new OrderDto { Id = x.Id, ... })，避免查出实体再映射
自定义扩展方法容易踩 IQueryable 翻译陷阱
给 IQueryable<t></t> 写扩展方法时，参数必须是 Expression<func bool>></func> 才能参与 SQL 构建；如果误写成 Func<t bool></t>，方法内部哪怕只是包装一层 Where，也会导致运行时被当作内存操作处理。
例如这个错误写法：
public static IQueryable<T> WhereActive<T>(this IQueryable<T> query, Func<T, bool> predicate)
=> query.Where(predicate); // ❌ predicate 是 Func，不是 Expression
正确写法：
public static IQueryable<T> WhereActive<T>(this IQueryable<T> query, Expression<Func<T, bool>> predicate)
=> query.Where(predicate); // ✅ 可被 EF 翻译
更隐蔽的问题是：某些扩展方法看似无害，但内部用了 ToList() 或 Count()，会强制执行查询 —— 比如一个叫 .ToPagedResult() 的封装，如果它内部先调了 .Count() 再 .Skip().Take()，就会查两次数据库。
这类逻辑必须拆成两步：先构造 IQueryable，再分别调用 .CountAsync() 和 .ToListAsync()，且确保两者基于同一个未执行的查询源。
