EF Core中Skip/Take实现数据库分页必须满足三条件：保持IQueryable、强制OrderBy排序、避免提前枚举，否则退化为内存分页导致OOM或超时；深分页性能差因数据库需扫描前N行，且无OrderBy会导致结果不可靠。
EF Core 的 Skip + Take 能实现数据库级分页，但必须满足三个硬性条件：查询保持为 IQueryable<t></t>、必须带 OrderBy、不能提前触发枚举（如 ToList()）。不满足任一条件，就会退化成内存分页，大数据量下直接 OOM 或超时。
为什么 Skip/Take 在 EF Core 里会变慢甚至崩溃
根本原因在于执行时机和 SQL 翻译逻辑：
-
Skip(10000).Take(20)在数据库中本应翻译为OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY（SQL Server）或LIMIT 20 OFFSET 10000（PostgreSQL/MySQL），但前提是整个链路没被“提前终结” - 一旦中间调了
AsEnumerable()、ToList()、ToArray()或AsNoTracking().ToList()，EF 就放弃翻译，把全表查出来再内存裁剪——100 万行数据跳到第 500 页，就得先加载 50000 行进内存 - 错误日志里不会报错，只会看到 CPU 暴涨、GC 频繁、响应时间从 50ms 崩到 8s+，甚至
OutOfMemoryException - 深分页（如
Skip(500000)）即使走对了 SQL，数据库也要扫描前 50 万行，索引失效风险高，不是代码问题，是设计瓶颈
必须加 OrderBy，否则结果不可靠
关系型数据库不保证无序查询的物理顺序。没有 OrderBy 时，Skip(10).Take(5) 可能在两次请求间返回不同数据，甚至重复或漏掉记录。
- SQL Server 在启用
OFFSET/FETCH时强制要求ORDER BY，否则抛SqlException - PostgreSQL/MySQL 虽不强制，但不加
OrderBy会导致分页“漂移”——用户翻页时看到旧数据反复出现 - 排序字段最好选有唯一索引的列（如主键
Id），避免用Name这类可能重复的字段；若必须用非唯一字段，建议拼上主键兜底：OrderBy(p => p.Status).ThenBy(p => p.Id)
如何安全传参并防越界
Skip 和 Take 参数必须来自受控输入，不能拼接字符串，也不能放任前端传负数或超大值。
- 页码和页大小建议做服务端校验：
if (pageNumber 100) throw new ArgumentException(...); - 计算跳过数时用
(pageNumber - 1) * pageSize，别写成pageNumber * pageSize—— 第 1 页就该跳 0 条 -
Skip(n)中n超过总行数不会报错，而是返回空集合，这掩盖了“页码超出范围”问题；建议配合CountAsync()先查总数，再判断是否越界 - 组合顺序不能颠倒：
Take(10).Skip(20)等价于Take(10)，因为先取 10 条后已无剩余可跳
带总数的分页要拆成两个查询
别试图在一个查询里同时取数据和总数，EF Core 不支持 IQueryable 上直接调 Count() + Skip().Take() 合并执行。必须分两步：
- 第一步查总数：
await context.Products.Where(...).CountAsync()，确保Where条件和分页查询完全一致 - 第二步查数据：
await context.Products.Where(...).OrderBy(...).Skip(...).Take(...).ToListAsync() - 虽然多一次 round-trip，但这是最稳定、最易调试的方式；想省一次查询可用缓存总数，但要注意并发更新导致的不一致
- 如果总数超大（比如千万级），且前端只显示「是否有下一页」，可用
AnyAsync()+Skip(n).Take(1)替代全量CountAsync()，性能提升明显
真正难的不是写对 Skip 和 Take，而是守住 IQueryable 的“纯洁性”——任何一次不经意的 ToList()、任何一处漏掉的 OrderBy、任何一个没校验的页码参数，都会让分页从数据库级瞬间跌回内存级。游标分页（基于上一页末尾 ID 查询）在无限滚动场景下更稳，但 Skip/Take 仍是管理后台类应用的默认选择，前提是你盯紧那三条铁律。
