ajax分页关键在于前后端协作按需加载：前端传全pagenum、pagesize等参数并防抖节流渲染，后端用数据库原生分页（非内存截取）返回含data和pageinfo的结构化json。
JavaScript 中用 Ajax 处理大批量数据分页，关键不是“一次性拉完再分”，而是让前后端协作，按需加载、精准查询、轻量传输。核心在于：前端只管触发和渲染，后端负责计算偏移、限制条数、返回结构化数据。
分页参数必须传全
每次 Ajax 请求都要带上这几个必要参数，缺一不可：
- pageNum：当前页码（从 1 开始，别从 0）
- pageSize：每页几条（建议 10–50，太大易卡顿，太小请求频繁）
- totalRecord（可选但推荐）：总数据量——由后端查 count(*) 返回，前端据此算 totalPage、控制页码按钮显隐
- 条件字段：如 keyword、status、dateRange 等，拼在 URL 或 request body 里，避免无效全量扫描
后端要支持真分页，不是内存截取
前端发来的 pageNum 和 pageSize，必须交由数据库原生分页处理，比如：
- MySQL：
LIMIT (pageNum-1)*pageSize, pageSize - Oracle/PostgreSQL：用
OFFSET ... FETCH NEXT ... ROWS ONLY或ROWNUM包裹 - MyBatis/MyBatis-Plus：直接用
<pagehelper></pagehelper>或Page<t></t>对象，自动注入分页 SQL
千万别在 Java 层查出全部数据再 list.subList() —— 百万级数据一查就 OOM。
响应格式统一，带分页元信息
后端返回的 JSON 至少包含两部分：
-
data：当前页的数组列表（如
[{id:1,name:"A"},{id:2,name:"B"}]） -
pageInfo：分页上下文，例如：
{ "pageNum": 3, "pageSize": 20, "total": 1247, "pages": 63, "hasNext": true, "hasPrevious": true }
前端靠 total 和 pageSize 算出总页数；靠 hasNext/hasPrevious 控制“下一页”“上一页”按钮是否可用，比硬写页码逻辑更可靠。
前端渲染要防抖+节流+状态管理
用户狂点页码或滚动太快时，得避免并发请求把页面搞乱：
- 点击翻页按钮前加
disabled，请求中置灰，成功后再恢复 - 用 Promise 链或 async/await 控制顺序，不允许多个 pending 请求同时更新同一块 DOM
- 滚动加载（无限分页）场景下，监听
scroll事件前加节流（如 200ms 一次），且判断scrollTop + clientHeight >= scrollHeight - 100再触发下一页 - 清空旧数据再插入新数据，或用 key 做 diff（React/Vue 场景），避免残留旧项
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
