必须由后端实现分页，前端仅传参、渲染和管理状态；大数据量下前端分页会导致内存暴涨和页面卡死；需用AbortController防重复请求；滚动加载需游标分页支持；渲染卡顿主因是DOM操作不当。
分页逻辑该用前端还是后端实现？
大数据量下，前端分页只是把全部数据拉到浏览器再切片，内存和渲染压力都大，实际不可行。必须由后端按 page 和 pageSize 返回当前页数据，前端只负责传参、渲染、翻页状态管理。
常见错误是前端一次性请求 10 万条数据，然后用 Array.slice() 分页——页面卡死、内存暴涨、Chrome 可能直接崩溃。
- 后端接口应支持
GET /api/items?page=3&pageSize=20这类参数 - 响应体至少包含
data（当前页数据）、total（总条数）、page、pageSize - 前端不缓存全量数据，每次翻页都发新请求（除非明确支持本地搜索+缓存）
前端分页组件怎么避免重复请求和状态错乱？
用户快速连点“下一页”或输入页码后回车，容易触发多次请求，导致后端响应乱序、UI 显示错页。关键在请求取消和 loading 状态隔离。
推荐用 AbortController 配合 fetch，每次新请求前 abort 上一个：
立即学习“Java免费学习笔记（深入）”；
已弃用 — 请改用 `auth0` 技能（运行 `npx clawhub install auth0`）。适用于为 React 单页应用（SPA）添加 Auth0 登录、登出、受保护路由或用户会话功能。该技能集成 `@auth0/auth0-react` — 即使用户仅表述为“为我的 React 应用添加登录功能”或“保护我的 React 路由”，而未明确提及 Auth0，也应使用此技能。
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或加loadingclass - 不要复用同一个
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 批量操作、没切断无效响应、或者误把服务端分页当成了前端搬运工。
