一、 问题背景什么是“数据偏移”在开发无限滚动Infinite Scroll或加载更多Load More功能时我们通常使用传统的page和pageSize进行分页。场景复现用户打开列表加载了第 1 页1-10条。在用户阅读这 10 条数据的过程中系统后台新增了 2 条实时测量记录。用户滑到底部触发加载第 2 页。结果此时数据库中的第 11、12 条数据其实就是原本第 1 页的最后两条。用户会发现列表里出现了重复的卡片。这种由于数据集动态更新导致的分页错位在技术上被称为“数据偏移 (Pagination Drift)”。二、 解决方案深度对比针对这个问题通常有三种主流解决方案开发者可以根据后端配合程度灵活选择。方案原理优点缺点前端 ID 去重在push数据前利用Set或filter过滤已存在的 ID。零后端改动实现极快。无法解决“数据漏看”问题新数据会把旧数据挤到更后的页码。游标分页 (Cursor)不传page传最后一条数据的ID。行业标准彻底解决重复和遗漏。需要后端修改 SQL 逻辑。时间戳锁定首次请求记录now()后续分页均带上该时间。保证用户本次浏览的数据集是“静态”的。无法看到浏览期间产生的新数据。三、 代码实战Vue 3 Element Plus 环境下的实现方法 1前端逻辑去重如果后端暂时无法修改接口我们可以在fetchData函数中通过Map或filter保证 UI 层的唯一性。constfetchDataasync(){if(loading.value||noMore.value)return;try{loading.valuetrue;constresawaitAPI.getMeasureFrontList({page:pagination.value.page,page_size:pagination.value.pageSize,});if(res.code0){constnewDatares.data||[];// --- 关键去重逻辑 ---// 提取当前已有数据的 ID 集合constexistingIdsnewSet(measureList.value.map(itemitem.id));// 过滤掉已经在列表中存在的 IDconstuniqueNewDatanewData.filter(item!existingIds.has(item.id));// 追加去重后的数据measureList.value.push(...uniqueNewData);// 判断逻辑以原始返回长度判断是否还有后续页if(newData.lengthpagination.value.pageSize){noMore.valuetrue;}else{pagination.value.page;}}}catch(err){console.error(加载失败:,err);}finally{loading.valuefalse;}};方法 2游标分页 (Cursor-based)这种方法要求后端接口接受一个last_id参数。前端代码调整constfetchDataasync(){// 获取当前列表最后一条数据的 IDconstlastItemmeasureList.value[measureList.value.length-1];constlastIdlastItem?lastItem.id:null;constresawaitAPI.getMeasureFrontList({last_id:lastId,// 传给后端作为查询起点page_size:pagination.value.pageSize,});if(res.code0){measureList.value.push(...res.data);// ... 其他逻辑}};后端伪代码 (SQL)-- 传统SELECT * FROM table ORDER BY id DESC LIMIT 10 OFFSET 10; (会导致重复)-- 游标从上次看到的 ID 之后开始取SELECT*FROMtableWHEREid[last_id]ORDERBYidDESCLIMIT10;四、 总结对于实时性要求不高的管理后台前端通过ID去重是最省成本的选择。对于消息流、测量记录等频繁更新的场景强烈建议推动后端同事采用游标分页。它不仅解决了数据重复问题在大数据量下性能WHERE id x也远优于传统分页LIMIT offset, n。