必须由后端实现分页，前端仅传参、渲染和管理状态；大数据量下前端分页会导致内存暴涨和页面卡死；需用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免费学习笔记（深入）”；
本书是全面讲述PHP与MySQL的经典之作，书中不但全面介绍了两种技术的核心特性，还讲解了如何高效地结合这两种技术构建健壮的数据驱动的应用程序。本书涵盖了两种技术新版本中出现的最新特性，书中大量实际的示例和深入的分析均来自于作者在这方面多年的专业经验，可用于解决开发者在实际中所面临的各种挑战。 本书内容全面深入，适合各层次PHP和MySQL开发人员阅读，既是优秀的学习教程，也可用作参考手册。
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 批量操作、没切断无效响应、或者误把服务端分页当成了前端搬运工。
