上拉加载不拖慢分页，但实现不当会严重拖慢：重复请求、无节流dom追加、未清理监听器、滚动中高频判断是主因；应节流scroll、用intersectionobserver+rootmargin提前触发、游标分页、虚拟滚动优化渲染。
上拉加载本身不会拖慢分页数据，但实现方式不当会严重拖慢
上拉加载（infinite scroll）只是触发时机不同，底层仍是发请求、解析、渲染——真正拖慢的从来不是“上拉”这个动作，而是重复请求、无节流的 DOM 追加、未清理的监听器，以及在滚动中高频执行的判断逻辑。
常见错误现象：scroll 事件里直接调用 fetch、每次追加都用 innerHTML +=、没做节流导致一帧内触发多次加载、IntersectionObserver 配置了过小的 rootMargin 导致提前触发。
- 滚动监听必须加节流（推荐用
requestIdleCallback或setTimeout延迟 100ms 再检查） - 避免在
scroll中直接调用异步请求；先判断是否接近底部，再触发加载逻辑 - 使用
document.createElement+DocumentFragment批量插入，比反复操作innerHTML快 3–5 倍
用 IntersectionObserver 替代 scroll 监听更稳定
IntersectionObserver 是现代浏览器处理“元素进入视口”最轻量的方式，它不绑定滚动帧，也不抢占主线程，天然防抖。尤其适合监听“加载占位符”是否可见。
使用场景：页面底部固定一个 <div id="loader-trigger"></div>，交由 IntersectionObserver 观察其是否进入视口，再触发下一页请求。
- 务必设置
rootMargin: '0px 0px 200px 0px'，让加载提前 200px 触发，避免用户拉到底才开始请求 - 观察器创建后，首次触发可能立即回调，需用
observer.takeRecords()或标记位防止重复加载 - 加载中状态要禁用再次触发（比如给
#loader-trigger加data-loading="true"并在 observer 回调开头检查）
分页参数传错或没缓存会导致重复请求同一页
上拉加载依赖正确的分页上下文：当前页码、每页条数、总条数、是否还有下一页。一旦这些信息丢失或错乱，就可能反复请求第 2 页甚至第 1 页，用户看到数据“闪回”或“卡住”。
典型错误：把 offset 当成页码用（如 offset = (page - 1) * limit），但前端没保存上次的 offset，滚动后重新计算出错；或者服务端返回的 next_cursor 没被前端正确提取并透传。
- 优先用游标（cursor）而非页码：服务端返回
next_cursor字段，前端只负责透传，不自己算页码 - 加载中把当前请求的
cursor存进组件 state 或data-属性，防止滚动多次触发相同请求 - 网络失败时，不要自动重试；应保留上次成功加载的数据，并提示用户手动刷新或点击重试按钮
DOM 节点过多时渲染变卡，必须做虚拟滚动或分组卸载
当加载超过 500 条数据后，哪怕只是纯文本列表，document.querySelectorAll('.item').length 查询也会明显变慢，滚动帧率跌破 30fps。这不是分页问题，是渲染瓶颈。
解决思路不是“少加载”，而是“少渲染”。真实项目中，99% 的用户不会滚动到第 200 条，没必要让所有 DOM 节点常驻内存。
- 简单方案：每加载 20 页后，用
document.querySelector('.item:nth-child(-n+200)')批量移除前 N 个节点（保留可视区上方 50 条缓冲） - 进阶方案：改用
react-window或原生virtual-scroller，只渲染视口内 ±2 屏的内容 - 警惕 CSS：避免对大量元素使用
box-shadow、filter、transform等触发全层绘制的样式
实际中最容易被忽略的是“加载完成后的滚动位置保持”——用户拉到第 8 页，刷新页面后回到顶部，体验断裂。这需要配合 history.replaceState 记录当前 cursor，或服务端支持锚点跳转。但那是另一个链路的问题了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
