Node.js后端如何实现无限滚动？除记录最后项ID查询外还有其他方案吗？

云原生阿岚

2026-5-25

嘿，这个问题问得很到位！你提到的记录最后一条数据ID，查询其后数据确实是实现无限滚动最常用也最靠谱的方案之一，但还有几种不同的实现思路，我给你拆解清楚，帮你根据场景选最合适的：

1. 基于ID的分页（你最先想到的方案）

这应该是最直观也最不容易出问题的方案，核心逻辑就是：

前端每次请求时，带上列表最后一条数据的ID
后端用这个ID作为查询条件，只返回ID比它大（或者小，看排序方向）的N条数据
同时返回一个hasMore标记，告诉前端是否还有更多数据可以加载

举个Node.js的实际代码例子，假设用Express + MongoDB：

// 后端接口示例
app.get('/api/articles', async (req, res) => {
  const { lastArticleId, pageSize = 10 } = req.query;
  let query = {};

  // 如果有上次的最后ID，就过滤出ID更大的内容
  if (lastArticleId) {
    query._id = { $gt: new mongoose.Types.ObjectId(lastArticleId) };
  }

  // 多查一条数据，用来判断是否还有更多内容
  const articles = await Article.find(query)
    .sort({ _id: 1 }) // 按自增ID升序排列，保证顺序正确
    .limit(parseInt(pageSize) + 1);

  const hasMore = articles.length > parseInt(pageSize);
  // 把多查的那条去掉，只返回请求的数量
  const responseData = hasMore ? articles.slice(0, -1) : articles;

  res.json({
    data: responseData,
    hasMore,
    lastId: responseData.length > 0 ? responseData[responseData.length - 1]._id : null
  });
});

如果是用SQL数据库（比如MySQL），逻辑类似：

// SQL版本的查询逻辑
const query = `
  SELECT * FROM articles 
  WHERE id > ? 
  ORDER BY id ASC 
  LIMIT ?
`;
const [rows] = await db.query(query, [lastArticleId, pageSize]);

要注意的点：

这里的ID最好是自增有序的（比如MySQL的自增ID、MongoDB的ObjectId），这样才能保证查询的顺序和数据的加载逻辑一致
如果有数据被删除，会出现列表里的空缺，但不会影响无限滚动的连续性，只是少几条数据而已，一般用户感知不到

2. 基于时间戳的分页

如果你的数据没有合适的自增ID，或者业务需要按时间顺序加载（比如动态、评论），可以用时间戳来替代ID：

前端带上最后一条数据的created_at时间戳
后端用WHERE created_at > lastTimestamp来过滤

但这里有个坑：同一时间可能会有多条数据（比如同一秒创建10条评论），如果只按时间戳过滤，可能会漏数据或者重复加载。所以最好结合ID一起判断：

// MongoDB示例，结合时间戳和ID
query = {
  created_at: { $gte: lastTimestamp },
  _id: { $gt: lastId }
};

这样就能避免同一时间多条数据导致的问题。

3. 游标分页（Cursor-based Pagination）

其实前面两种都属于游标分页的范畴，不过有些数据库/ORM提供了更原生的游标支持，比如MongoDB的cursor对象、PostgreSQL的FETCH NEXT ... USING CURSOR。这种方案的优势是：

性能更好，尤其是大数据量的时候，不用像偏移量分页（OFFSET）那样扫描大量前置数据
完全避免了数据插入/删除导致的重复或漏加载问题

比如用MongoDB的游标：

// 用游标分页的简化示例
const cursor = Article.find().sort({ _id: 1 }).cursor();
// 第一次获取10条
const firstBatch = await cursor.nextBatch(10);
// 后续获取下一个10条
const nextBatch = await cursor.nextBatch(10);

不过这种方案需要后端维护游标状态，一般在长连接或者特定场景下用得更多，普通的HTTP接口还是前面两种更实用。

避坑提醒：别用偏移量分页！

很多人一开始会想到用LIMIT pageSize OFFSET offset来实现，但这种方案有两个致命问题：

性能差：当offset很大时（比如加载第1000页），数据库需要先扫描前999*pageSize条数据，再返回后面的10条，效率极低
数据不一致：如果在两次请求之间有数据插入或删除，会导致列表出现重复数据或者漏加载的情况

所以除非是小数据量的后台管理系统，否则千万别用偏移量分页来做无限滚动。

最后，前端也要配合好：监听滚动事件（或者用Intersection Observer API），当用户滚动到列表底部附近时，调用后端接口，带上上次返回的lastId或lastTimestamp，把新数据追加到现有列表里，直到hasMore为false就停止请求。

内容的提问来源于stack exchange，提问作者dqmis