在Node.js后端服务里，列表接口几乎都要面对分页查询。随着业务数据增长，同样是取每页二十条，第一页和第一千页的耗时可能相差几十倍。这背后其实是分页策略的选择问题，Skip/Limit和游标分页在原理与适用面上都有明显分野。
Skip/Limit分页的实现机制与隐患
Skip/Limit是最直观的分页方式，核心逻辑是告诉数据库从结果集的第N条开始跳过，再取固定数量。在Node.js中配合MongoDB的官方驱动，通常根据前端传来的页码page和页大小pageSize，算出skip值为(page-1)*pageSize，然后调用find查询并链式调用skip与limit。这种做法对开发者非常友好，前端也能随意跳转到任意页码。
然而当偏移量变大，数据库并不能凭空从第十万条开始读，它依旧要先定位到满足条件的文档并按索引或全表顺序扫描，再在内存或游标中丢弃前面被跳过的数据。下面是一段典型的Node.js代码：
const MongoClient = require('mongodb').MongoClient;
async function getUsersByPage(page, pageSize) {
const client = await MongoClient.connect('mongodb://127.0.0.1:27017');
const db = client.db('test');
const coll = db.collection('users');
const skip = (page - 1) * pageSize;
// 使用创建时间倒序，保证分页顺序稳定
const list = await coll.find({}).sort({ createdAt: -1 })
.skip(skip).limit(pageSize).toArray();
const total = await coll.countDocuments({});
await client.close();
return { list, total, page, pageSize };
}
上述代码在page较小时响应很快，但深翻页时skip值巨大，MongoDB必须遍历并丢弃前skip条记录。如果排序字段没有合适索引，还会触发全表扫描。此外，如果在翻页过程中有新数据插入且排序靠前，会导致后续页面数据重复或遗漏，因为偏移基准发生了偏移。
从资源占用看，Skip/Limit在深分页下CPU和IO消耗呈线性上升，对共享数据库实例非常不友好。它适合后台管理系统中小数据量、需要任意跳页的场景，而不适合面向C端用户的无限下拉或深翻页列表。
游标分页的底层原理与代码实践
游标分页又称seek method，基本思路是不记录跳过多少条，而是记录上一页最后一条记录的有序字段值，下一页查询时直接取该值之后的数据。它依赖一个唯一且有序的字段组合，比如createdAt加_id，利用索引做范围查询，数据库只需从游标位置往后读，无需丢弃历史数据。
在Node.js里实现时，前端不再传page，而是传lastCreatedAt和lastId。查询条件变为createdAt小于上一页末值，或createdAt相等但_id小于上一页末_id，再limit取页大小。示例如下：
const MongoClient = require('mongodb').MongoClient;
async function getUsersByCursor(lastCreatedAt, lastId, pageSize) {
const client = await MongoClient.connect('mongodb://127.0.0.1:27017');
const db = client.db('test');
const coll = db.collection('users');
const query = {};
if (lastCreatedAt && lastId) {
// 组合条件：时间更早，或同时间但id更小
query.$or = [
{ createdAt: { $lt: new Date(lastCreatedAt) } },
{ createdAt: new Date(lastCreatedAt), _id: { $lt: lastId } }
];
}
const list = await coll.find(query).sort({ createdAt: -1, _id: -1 })
.limit(pageSize).toArray();
await client.close();
return list;
}
这段代码每次查询都命中createdAt与_id的复合索引，无论翻多少页耗时都基本恒定。由于基于游标位置而非偏移，插入新数据不会影响已翻到的位置，不会重复或漏数据。缺点是前端不能随机跳到第N页，只能上一页下一页或无限滚动，且排序规则必须固定。
游标分页对数据库压力小，是Feed流、评论列表、订单流水等场景的首选。若业务必须支持跳页，可在游标基础上对前几页用Skip/Limit，深页引导用户顺序浏览，从而兼顾体验与性能。
两种方案的性能对比与选型建议
从查询计划角度，Skip/Limit在大偏移时执行explain会显示大量被丢弃的keysExamined和docsExamined，而游标分页的扫描量恒等于页大小。我们用一张简表说明差异：
| 维度 | Skip/Limit | 游标分页 |
|---|---|---|
| 深翻页耗时 | 随偏移线性增长 | 基本恒定 |
| 跳页支持 | 任意页码 | 仅顺序翻页 |
| 数据一致性 | 易因插入导致错位 | 不受插入影响 |
| 索引要求 | 排序字段需索引 | 游标字段需复合索引 |
在Node.js项目中，如果列表面向运营后台且数据不过百万，用Skip/Limit开发效率最高。若是高并发C端接口，应优先采用游标分页，并将游标值编码进base64返回给前端，避免暴露内部字段。还可以用Redis缓存热门前缀页，进一步降低数据库负载。
实际落地时，建议在数据访问层封装统一分页接口，根据入参自动路由。例如检测到前端传page则走Skip/Limit，传cursor则走游标查询，上层控制器无需感知差异。这样既有灵活度，也方便后续全量切到游标方案而不动业务代码。
最后要注意，无论哪种分页，都应为排序字段建立正确索引，并避免在前端拼装不受信任的skip值。通过慢查询日志观察executionTimeMillis，能快速定位是否该从Skip/Limit迁移到游标分页。