无限滚动和传统分页是场景强绑定的加载策略，非单纯性能对比：无限滚动依赖滚动监听自动加载，易致重复请求与内存暴涨；传统分页通过页码跳转控制请求边界，保障url可分享、seo可见及位置可追溯。
无限滚动和传统分页不是性能高低的二选一，而是加载策略与使用场景强绑定的两种方案——选错会导致卡顿、内存暴涨、用户找不到内容，甚至影响 SEO 和可访问性。
滚动触底自动加载 vs 页码跳转：触发机制决定底层行为
无限滚动依赖 window.onscroll 或更推荐的 IntersectionObserver 监听底部占位元素是否进入视口；传统分页则由用户显式点击触发，每次请求都带 page 和 pageSize 参数。前者容易因频繁触发导致重复请求（尤其快速滚动时），后者天然具备明确的请求边界。
- 用
IntersectionObserver替代onscroll可避免节流逻辑写错，也更省 CPU - 无限滚动必须做请求防重：上一个
fetch未完成时，新触发的加载应被丢弃或中断（用AbortController） - 传统分页若混用前端分页（只对已加载数据切片），而接口实际是后端分页，会出现“翻页后数据消失”或“总数不准”
DOM 节点数量与内存占用：虚拟滚动不是无限滚动的替代品
无限滚动默认会持续追加 DOM 节点，1000 条后页面可能含上万节点；传统分页每页只渲染固定数量（如 20–50 条），DOM 总量可控。但要注意：虚拟滚动（如 vue-virtual-scroll-list）和无限滚动解决的是不同问题——前者管“长列表渲染效率”，后者管“内容加载时机”，二者可共存（例如：用虚拟滚动渲染无限滚动加载进来的数据块）。
- 纯无限滚动 + 不清理旧节点 → 内存持续增长，Chrome 中观察到内存从 80MB 涨到 200MB+ 很常见
- 虚拟滚动初始渲染稍慢（需计算可视区域），但滚动 FPS 稳定在 55–60，传统分页翻页瞬间常掉到 10–20 FPS
- 虚拟滚动要求列表项高度尽量一致，否则估算偏差会导致空白或重叠
用户能“回到第 17 页”吗？URL 与历史记录是硬分水岭
传统分页天然支持 URL 同步：/search?page=17&size=20 可分享、可刷新、可书签；无限滚动若不做额外处理，地址栏始终不变，用户关闭标签页再打开就只能从头开始。这不是体验优化问题，而是功能缺失。
- 想保留页码跳转能力，就别强行用一套逻辑覆盖所有场景——小红书的做法是：信息流页用无限滚动，搜索结果页切回传统分页
- 若坚持无限滚动也要支持定位，得配合
history.pushState手动更新 URL，并监听popstate恢复滚动位置（注意 SSR 下需服务端同步渲染对应数据） - SEO 友好性几乎无法补救：爬虫不执行 JS，也不会滚到底部触发加载，首屏外内容基本不可见
真正难的不是实现，而是判断“这个列表是否允许用户丢失位置”。如果业务需要导出全部、按页统计、审计追踪或支持屏幕阅读器逐页导航，传统分页不是过时方案，而是必要约束。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
