skip + take 不是真正的数据库分页而是内存分页，因其仅在 ienumerable 或提前枚举的 iqueryable 上操作；若源为数据库但已调用 tolist() 等，则全量加载后裁剪，易致 oom 或性能陡降。
为什么 Skip + Take 不是真正的分页，而是内存分页
因为 Skip 和 Take 作用在已加载到内存的 IEnumerable<t></t> 或 IQueryable<t></t> 上，如果源数据来自数据库但没走 IQueryable（比如先调了 ToList()），那整个集合会先被拉进内存再裁剪——大数据量时直接 OOM 或卡死。
常见错误现象：System.OutOfMemoryException、响应时间随总数据量线性增长、分页跳转越往后越慢。
- 使用场景：仅适用于小数据集（如配置项列表、用户本地缓存数据、测试数据）
- 如果是 EF Core 查询，必须确保链式调用中没提前触发枚举（避免
AsEnumerable()、ToList()、ToArray()） -
Skip(0).Take(10)和Skip(1000).Take(10)在内存中性能差异极小，但在数据库层面，后者本应只查 10 条，一旦进内存就查了 1010 条
怎么写才让 Skip + Take 走数据库而不是内存
关键看类型：必须保持为 IQueryable<t></t>，直到最后调用 ToListAsync() 或 ToList() 才真正执行 SQL。
错误写法：context.Users.ToList().Skip(20).Take(10) → 全表查出再裁剪
正确写法：context.Users.Skip(20).Take(10).ToListAsync() → 生成 OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY（SQL Server）或等效语句
- EF Core 5+ 支持原生分页语法，低版本可能降级为子查询，性能略差但仍是数据库侧执行
- 注意
OrderBy必须存在，否则 SQL Server 报错，SQLite 可能返回不稳定结果 - 参数要安全传入，别拼字符串：
Skip(pageIndex * pageSize)没问题，$"SKIP {pageIndex * pageSize}"是漏洞
Skip 和 Take 的边界行为容易踩坑
Skip(n) 当 n 大于集合长度时不会报错，而是返回空序列；Take(n) 同理，超出长度就取到末尾为止——这看似友好，但掩盖了“页码越界”问题。
常见错误现象：请求第 1000 页（每页 10 条），但总共只有 200 条数据，接口静默返回空数组，前端以为“没数据”而非“页码无效”
- 建议在分页前加总数检查：
var totalCount = await context.Users.CountAsync() -
Skip(-1)会抛ArgumentOutOfRangeException，别用负数 -
Take(0)合法，返回空序列，可用于短路逻辑，但别误以为是“跳过全部” - 组合顺序不能反：
Take(10).Skip(20)等价于Take(10)，因为先取 10 条再跳 20 —— 肯定没得跳
分页参数怎么传才不容易崩
页码和每页数量必须校验，尤其来自 API 查询参数时，int 类型解析失败或超范围会导致异常或非预期行为。
错误写法：int pageIndex = int.Parse(Request.Query["page"]); → 无校验，400 或 500
推荐做法：用模型绑定 + [Range] 特性，或手动解析并设默认值
-
pageIndex应从 0 开始（对应Skip(pageIndex * pageSize)），若前端传的是“第 1 页”，需减 1 -
pageSize建议硬限制上限（如 ≤ 100），防恶意大值拖垮数据库 - EF Core 中，
Skip值过大（如上亿）可能触发数据库自身限制，SQL Server 对OFFSET无硬上限，但性能急剧下降
分页逻辑里最容易被忽略的，是没确认数据源是否还处于可翻译状态——只要中间多一个 .AsEnumerable()，后面所有 Skip/Take 就全掉内存里了。
