React实现的服务端分页无限滚动删除后分页错位问题咨询

这类场景下的数据丢失问题，本质是基于偏移量（offset/limit）的传统服务端分页，天然不匹配存在动态删除操作的无限滚动场景。
当前Spring侧的分页逻辑通常是按固定规则计算偏移量：LIMIT 单页大小 OFFSET (页码 - 1) * 单页大小，这套逻辑的基准是“列表的条目相对位置”——只要在已加载的列表里删除任意1个条目，后续所有条目的相对位置都会整体前移1位，之前和前端约定的“page2对应第21~40条数据”的基准就会完全失效，最终出现数据遗漏、位置错位的问题。
这不是无限滚动本身和删除操作不兼容，是分页方式的选型问题。

方案1：后端改造为游标（Cursor）分页（推荐，长期稳定方案） #

这是带动态增删的长列表无限滚动的通用标准实现，完全从根源上解决偏移量错位的问题。

• 核心改造点：
  • 废弃“前端自增页码、后端算offset”的逻辑，改为用列表的稳定排序值做分页游标：
    1. 接口首次请求不携带任何分页标识，后端按固定排序规则（比如创建时间倒序、ID倒序）返回第一页数据，同时在响应里附带当前页最后1条数据的唯一稳定游标值（推荐用最后一条的创建时间 + 条目ID的组合值，联合索引可保证查询效率，且不会因为条目前置的删除、新增发生数值变化）
    2. 前端后续加载下一页时，直接把上一次拿到的游标值传给后端
    3. 后端的下一页查询逻辑改为：查询所有排序值 < 已传递游标值的数据，按单页大小截取返回，全程不计算偏移量
• 匹配示例的流程验证：
  1. 首次请求不带游标，拿到总26条里的前20条，附带最后一条的游标值（比如lastCreateTime:2024-05-20 14:00, lastId:20）
  2. 删除已加载列表里的任意1条，剩下19条——但那个游标值对应的第20条数据，它的创建时间、ID从来没变化，排序位置也没有变动
  3. 滚动加载下一页时，带上这个游标值请求，后端会精准查询所有排在第20条之后的6条数据，不管之前在前20条里删了多少内容，拿到的永远是紧挨着已加载列表末尾的连续数据，不会出现漏数、跳数
• Spring实现注意：给查询表的create_time + id字段建联合索引，游标查询全程走索引，性能和原有offset分页一致，也不会出现深分页的性能衰减问题。

方案2：前端做偏移量校准（临时过渡方案，无需改后端） #

如果短期没有时间调整后端分页逻辑，可以通过前端的删除操作计数，校准每次分页请求的实际位置：

• 核心逻辑：
  1. 在Context的列表数据状态里，新增1个删除计数变量，每成功删除1个已加载的列表项，计数+1
  2. 下一次发起分页请求时，不直接使用固定页码计算偏移，而是按实际已加载的有效条目数计算请求位置：实际请求起始偏移量 = 已加载总条数 - 删除计数，对应的后端请求页码为Math.ceil(实际请求起始偏移量 / 单页大小) + 1
• 匹配示例的流程验证：
  1. 首次加载page1，拿到20条数据，删除计数为0
  2. 删除1个条目后，实际渲染19条，删除计数变为1
  3. 滚动加载下一页时，计算实际请求偏移量=20-1=19，对应后端从第20条位置开始返回数据——原本被错位漏在page1末尾的那条数据，就会被这次请求拿到，不会出现数据丢失
• 方案缺陷：
  • 下一页返回的数据大概率会和已加载列表的末尾存在重复，需要前端用条目ID做一层去重，避免渲染重复项
  • 用户刷新页面、切换筛选条件时，删除计数会重置，校准逻辑直接失效
  • offset分页本身的深分页性能问题依然存在

• 无限滚动场景完全支持删除操作，只要分页基准不是会被前置操作改动的相对偏移量，就不会出现数据错位
• 删除操作后不需要触发全量列表重拉：这种做法会导致列表滚动位置跳变、接口请求量暴涨，体验极差

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