分页必须先skip再take，且需配合orderby排序，否则结果不稳定；skip偏移量应为(page-1)*pagesize，页码须校验≥1；总数与分页查询应复用同一iqueryable避免不一致。
分页时 Skip 和 Take 的执行顺序不能颠倒
必须先 Skip 再 Take，否则会跳过错误的数据行。比如当前页是第 3 页、每页 10 条，页码从 1 开始，则应跳过前 20 条（(page - 1) * pageSize），再取 10 条。如果写成 Take(10).Skip(20)，实际是先取前 10 条、再对这 10 条尝试跳 20 行——结果为空。
常见错误现象：IQueryable 分页后返回空集合，但总条数正确；或只返回第 1 页数据，后续页全为空。
-
Skip参数必须是非负整数，传负数会抛ArgumentOutOfRangeException - 数据库端分页（如 EF Core）中，
Skip值过大可能触发性能警告，尤其没索引时 - 若用内存集合（
List<t></t>）调用Skip/Take，会先加载全部数据进内存再分页——慎用于大数据量
计算 Skip 偏移量时要小心页码起始值
前端传来的页码通常是 1 起始（第 1 页、第 2 页……），而 Skip 是按 0 起始的偏移量。直接用 page * pageSize 就会多跳一页。
正确公式是：(page - 1) * pageSize。例如 page=1 → Skip(0)，page=2 → Skip(10)，page=3 → Skip(20)。
- 如果 API 约定页码从 0 开始（少见），则可直接用
page * pageSize - 建议在服务层做校验：当
page 或 <code>pageSize 时直接返回错误，避免无效查询 - EF Core 6+ 对
Skip(0)有优化，但低版本可能生成冗余 SQL，不过不影响结果
分页必须配合排序，否则结果不稳定
SQL 标准规定：未指定 ORDER BY 时，数据库不保证行序。LINQ 中若没写 OrderBy 就直接 Skip/Take，EF Core 可能生成无序 SQL，导致同一页多次请求返回不同数据，甚至漏行、重复。
典型表现：刷新列表时某条记录“消失”或“重复出现”，尤其在有并发写入的场景下更明显。
- 排序字段最好选唯一且非空的列，如
Id或组合主键；避免仅按CreatedTime排序（可能有重复值） - 如果业务要求按多个字段排序（如
State优先，再按Id），必须显式写出ThenBy，否则Skip逻辑会错乱 - 内存分页（
AsEnumerable()后分页）也需先排序，否则List<t></t>的枚举顺序不固定
总数查询别和分页共用同一个 IQueryable
很多人习惯先 var query = db.Products.Where(...)，再分别调用 query.Count() 和 query.Skip().Take()。这看似简洁，但 EF Core 会为每次调用重新解析表达式树，可能生成两套略有差异的 SQL（尤其含导航属性或复杂条件时），导致总数和分页结果不一致。
更稳妥的做法是复用查询对象，或用 CountAsync + ToAsyncEnumerable 组合（EF Core 5+）。
- 不要在分页前调用
ToList()或ToArray()获取总数——这会让整个表查出来，完全失去分页意义 - 使用
CountAsync和ToListAsync分开执行，两者共享同一查询结构，语义清晰且可控 - 注意：某些数据库（如 SQLite）不支持子查询中的
OFFSET，此时Skip可能被客户端模拟，需确认 EF 日志输出的实际 SQL
分页看着简单，真正上线后出问题的，八成卡在排序缺失、偏移量算错、或总数与分页查询没对齐这三处。尤其是排序——它不是“让结果好看点”的可选项，而是分页逻辑成立的前提。
