不是必须，但skip() + limit()是最直接可控的分页方式；大数据量下应改用基于排序字段和索引的游标分页以避免线性性能下降。
分页必须用 skip() 和 limit() 吗？
不是必须，但这是最直接、最可控的方式。MongoDB 原生不支持 OFFSET/LIMIT 语法，skip() + limit() 是 Node.js 驱动中最常用组合。它简单、语义清晰，适合中小数据量场景。
注意：当 skip() 值很大（比如跳过 10 万条）时，性能会明显下降——MongoDB 仍需扫描并跳过前面所有匹配文档。这不是 Node.js 的问题，而是 MongoDB 查询机制决定的。
-
skip(0)和skip(100000)都要遍历索引或文档，后者耗时更长 - 如果集合有千万级数据且频繁深度分页，应改用游标分页（cursor-based pagination），基于
_id或时间字段做范围查询 - 确保分页字段（如
_id或createdAt）上有索引，否则skip()会全表扫描
如何安全计算 skip 值？别硬写 (page - 1) * limit
看似简单，但容易漏掉边界校验和类型转换。Node.js 默认接收的 query 参数是字符串，parseInt() 不带基数参数可能出错，负数或非数字输入会导致意外行为。
示例代码片段（使用原生 MongoDB Driver）：
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
const page = Math.max(1, parseInt(req.query.page, 10) || 1); const limit = Math.min(100, Math.max(1, parseInt(req.query.limit, 10) || 10)); const skip = (page - 1) * limit;
-
parseInt(x, 10)显式指定十进制，避免"08"被误解析为八进制 - 用
Math.max(1, ...)防止 page ≤ 0，Math.min(100, ...)限制单页最大条数，防暴力拉取 - 跳过值
skip可能超大，建议在数据库层加maxTimeMS保护，例如：.find(...).skip(skip).limit(limit).maxTimeMS(5000)
为什么分页响应里要返回总条数？countDocuments() 和 estimatedDocumentCount() 怎么选？
用户需要知道“还有多少页”，后端就得提供 total。但这两个计数方法行为不同，选错会导致总数不准。
-
countDocuments({ status: "active" })：执行实际查询，支持 filter，结果精确，但慢（尤其带复杂条件时） -
estimatedDocumentCount()：读取集合元数据，快，但不支持 filter，只返回总文档数，无法用于带条件的分页 - 如果分页带查询条件（如
{ category: "news" }），必须用countDocuments()；若只是无条件分页，且能接受近似值，可用estimatedDocumentCount()加缓存
别在同一个请求里串行执行 count + find——这会放大延迟。可以用 Promise.all() 并发，但要注意连接池压力。
用 Mongoose 时，paginate 插件靠谱吗？
像 mongoose-paginate-v2 这类插件封装了 skip/limit 和 countDocuments，省事，但隐藏了细节。
- 它默认对
countDocuments不设超时，大集合 + 复杂 filter 下可能卡住整个请求 - 部分版本对
sort字段处理不严谨，比如传入{ createdAt: -1 }时内部可能没正确应用索引 - 如果你需要游标分页、或想控制
maxTimeMS、或需兼容事务上下文，插件反而增加调试成本
小项目用插件没问题；中大型服务建议手写分页逻辑，把 skip、limit、count、sort 和索引策略都显式暴露出来——毕竟分页不是黑盒，它是数据访问路径的关键一环。
