必须由后端实现分页，前端仅传参、渲染和管理状态；大数据量下前端分页会导致内存暴涨和页面卡死；需用AbortController防重复请求；滚动加载需游标分页支持；渲染卡顿主因是DOM操作不当。

分页逻辑该用前端还是后端实现？

大数据量下，前端分页只是把全部数据拉到浏览器再切片，内存和渲染压力都大，实际不可行。必须由后端按 page 和 pageSize 返回当前页数据，前端只负责传参、渲染、翻页状态管理。

常见错误是前端一次性请求 10 万条数据，然后用 Array.slice() 分页——页面卡死、内存暴涨、Chrome 可能直接崩溃。

• 后端接口应支持 GET /api/items?page=3&pageSize=20 这类参数
• 响应体至少包含 data（当前页数据）、total（总条数）、page、pageSize
• 前端不缓存全量数据，每次翻页都发新请求（除非明确支持本地搜索+缓存）

前端分页组件怎么避免重复请求和状态错乱？

用户快速连点“下一页”或输入页码后回车，容易触发多次请求，导致后端响应乱序、UI 显示错页。关键在请求取消和 loading 状态隔离。

推荐用 AbortController 配合 fetch，每次新请求前 abort 上一个：

let controller = null;

function loadPage(page) {
  if (controller) controller.abort();
  controller = new AbortController();

  fetch(`/api/items?page=${page}&pageSize=20`, {
    signal: controller.signal
  })
    .then(r => r.json())
    .then(data => render(data));
}

• 点击页码按钮前先设 disabled 或加 loading class
• 不要复用同一个 controller 实例，每次请求都新建
• 如果用 axios，对应的是 CancelToken 或 AbortController（v0.27+ 原生支持）

滚动加载（infinite scroll）比传统分页更省事？

不是更省事，是换了一种压力分布方式：它把“翻页动作”隐式转为“滚动触底”，但对后端要求更高——必须支持基于游标（cursor）或时间戳的分页，否则无法避免重复或漏数据。

传统 offset/limit 分页在大数据量下性能差（OFFSET 100000 LIMIT 20 仍要扫描前 10 万行），而游标分页依赖上一页最后一条的 id 或 created_at：

GET /api/items?cursor=123456&limit=20
// 下一页请求用上一页返回的 last_id 作为新 cursor

• 前端需记录并传递 cursor，不能只靠页码推算
• 滚动加载必须处理“无更多数据”的视觉反馈，且禁用重复触发（比如加 isFetchingNext 标志）
• 用户想跳转到第 87 页？滚动加载做不到，得退回带页码的分页控件

表格渲染卡顿？别怪分页，先查 DOM 更新方式

即使只有 50 条数据，用 innerHTML += ... 拼接或频繁 appendChild 也可能卡顿。核心是减少重排（reflow）和重绘（repaint）次数。

• 用 document.createDocumentFragment() 批量插入节点
• React/Vue 用户注意：避免在循环中直接 setState 或修改响应式数组，应一次更新整个列表
• 超过 200 行建议加虚拟滚动（virtualized list），如 react-window 或原生 IntersectionObserver + 高度预估
• 表格列过多时，考虑懒加载列（比如展开“详情”才渲染隐藏字段）

分页本身只是数据切片策略，真正卡住你的，往往是没控制好 DOM 批量操作、没切断无效响应、或者误把服务端分页当成了前端搬运工。