该用 iqueryable 还是 ienumerable，核心看数据是否已在内存：未执行.tolist()等则用iqueryable；进内存后必须切回ienumerable，否则报错。
该用 IEnumerable<t></t> 还是 IQueryable<t></t>，核心就看数据是否已在内存里：没执行过 .ToList()、.ToArray() 或没被遍历过，就该用 IQueryable<t></t>；一旦进内存，后续所有操作必须切回 IEnumerable<t></t>，否则会报 System.InvalidOperationException: The LINQ expression could not be translated。
为什么 IQueryable.Where 和 IEnumerable.Where 看似一样，却不能混用
两者签名不同：IQueryable.Where 接收的是 Expression<func bool>></func>（表达式树），供 EF Core 翻译成 SQL；IEnumerable.Where 接收的是 Func<t bool></t>（委托），直接在内存中执行。
- 你在
IQueryable上误调IEnumerable.Where（比如先.AsEnumerable()再.Where），EF 就不再生成 SQL，而是把整张表拉进内存再过滤 - 常见错误写法：
context.Orders.AsEnumerable().Where(x => x.Status == "Shipped")—— 千万行订单全加载进内存才筛 - 正确做法：保持
IQueryable链路，直到最后需要结果时再.ToList()或遍历
分页时 Skip/Take 必须用 IQueryable，否则性能崩盘
IQueryable.Skip(n).Take(m) 会被翻译成 OFFSET n ROWS FETCH NEXT m ROWS ONLY，数据库只返回 m 条；而 IEnumerable.Skip(n).Take(m) 会先把全部数据枚举出来，再丢弃前 n 条——数据量一大，内存和网络都扛不住。
- 危险示例：
context.Products.AsEnumerable().Skip(5000).Take(20)→ 加载 5020 行甚至更多到内存 - 安全写法：
context.Products.OrderBy(x => x.Id).Skip(5000).Take(20)，且确保OrderBy存在（SQL OFFSET 要求有序） - EF Core 7+ 支持
AsNoTracking()配合分页，进一步减少实体跟踪开销
什么时候必须用 AsEnumerable()？以及它有多危险
AsEnumerable() 不是“转类型”工具，它是明确的性能断点：它强制触发查询、把当前结果集全量加载进内存，之后所有操作都在本地跑。
- 合理场景：需要调用 EF 不支持的 .NET 方法，比如
string.IsNullOrWhiteSpace()、自定义函数、DateTime.Now.AddDays()等 - 必须搭配小数据集使用，例如先用
IQueryable粗筛出几百条，再.AsEnumerable().Where(x => ComplexLocalLogic(x)) - 绝对避免：
context.Customers.AsEnumerable().Where(...)（无前置过滤）或在分页前调用
最易被忽略的一点：表达式树翻译失败往往不是语法错，而是你用了 EF Provider 当前版本不支持的 API（比如旧版 EF Core 不支持 DateTime.Today，但支持 DateTime.UtcNow.Date）。别急着换方案，先查对应 EF Core 版本的「Supported expressions」文档。
