HTML分页不提升加载速度，仅隐藏已加载数据；服务端分页（如offset/limit）才真正优化性能；超大数据量需游标分页或虚拟滚动。
HTML分页本身不提升数据加载速度
纯前端 HTML 分页（比如用 slice() 在浏览器里切数组、翻页只改 DOM）完全不减少首次请求的数据量，也不降低网络传输开销。它只是把已加载的数据“藏起来再显示”，用户点下一页时没有新请求，自然快——但这建立在「所有数据已一次性拉完」的前提下。一旦列表有 10 万条记录，fetch('/api/items') 返回的 JSON 就可能卡死页面，这时候分页只是把崩溃延迟到渲染阶段。
常见错误现象：RangeError: Invalid array length（Chrome 对超大数组分配失败）、滚动卡顿、内存占用飙升至几百 MB。
- 适用场景：总数据量 ≤ 5000 条，且更新不频繁（如后台管理端的静态配置列表）
- 不适用场景：商品搜索结果、日志流、实时消息列表
- 性能影响：首次加载时间 = 全量数据传输 + 解析 + 渲染，和不分页一样；后续翻页无网络耗时，但 JS 计算和 DOM 操作成本随页数增加而上升
服务端分页才是真正的加载优化手段
真正减少加载压力的是服务端按需返回数据，典型做法是接口支持 page 和 limit 参数，例如 GET /api/orders?page=3&limit=20。此时浏览器每次只拿当前页的 20 条，首屏秒开，内存干净，也便于加缓存和限流。
关键点在于前后端必须对齐语义：page 是从 1 开始还是从 0 开始？limit 是否允许客户端随意调大？有没有默认上限？
- 推荐参数设计：
offset=40&limit=20（比page=3更易计算，避免页码跳变导致重复/漏数据） - 后端必须校验：
limit建议硬限制为 ≤ 100，防止恶意请求拖垮数据库 - 兼容性注意：某些老 API 用
start/count，前端适配时别写死成page/size
前端分页组件容易踩的三个坑
哪怕用了服务端分页，前端封装不当也会引入 bug 或体验断层。最常被忽略的是状态同步问题。
- 用户在第 5 页点击搜索，新结果应从第 1 页开始，但组件没重置
currentPage→ 继续请求offset=80，返回空数组 - 接口返回了
total总数，但组件用Math.ceil(total / limit)算总页数，而服务端实际按游标或 last_id 分页，总数不可靠 → 页码栏显示“共 100 页”，点到最后一页却 404 - 用户快速连点“下一页”，触发多个并发请求，后发先至，导致界面显示第 6 页内容，但页码高亮仍停留在第 5 页 → 需用
AbortController取消前序请求，或加 loading 锁
什么时候该放弃传统分页？
当用户明显不需要“跳转到任意页”，而更关注连续浏览（比如信息流、聊天记录），或者数据实时变化（如监控告警），传统 offset/limit 分页会暴露严重缺陷：深度分页性能差（MySQL OFFSET 1000000 极慢）、新数据插入导致页偏移、无法稳定锚定位置。
此时应切换方案：
- 游标分页（cursor-based）：用上一页最后一条的
id或created_at作为下一次查询条件，如?cursor=12345&limit=20；优点是性能恒定、无偏移，缺点是不支持跳页 - 无限滚动：监听
scroll，触底自动加载下一批；需配合节流、占位符、历史滚动位置恢复 - 虚拟滚动（virtualized list）：只渲染可视区域 DOM，适合长列表；依赖
react-window或vue-virtual-scroller，但要求行高固定或可预估
真实项目里，分页不是“选一个组件贴上去”就完事，得看数据规模、更新频率、用户操作路径。最容易被忽略的是：服务端是否真在分页，还是只在前端假装分了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
