后端分页接口必须接收page和pageSize参数，返回list和total字段；禁用offset防越权，推荐主键游标分页；前端需校验参数、动态渲染、处理边界与错误，并保障移动端点击体验。
上万条数据必须走后端分页，前端只管渲染和翻页请求；几千条以内才考虑前端分页，否则页面卡死、内存暴涨是大概率事件。
后端分页接口怎么设计才不踩坑
接口必须接收 page 和 pageSize 两个参数，不能用路径式如 /users/2，也不能传 offset——后者容易被篡改导致越界读取敏感数据。
- 返回结构里必须带
list（当前页数据）和total（总条数），缺一不可；没有total就算不出总页数，分页控件直接瘫痪 - 数据库查询推荐用游标分页（比如 MySQL 的
LIMIT ? OFFSET ?），但要注意OFFSET超大时性能下降，百万级数据建议改用基于主键的游标（WHERE id > ? ORDER BY id LIMIT ?） - 别在响应里塞无关字段，比如把用户 token 或原始 SQL 日志一起返回——既暴露信息，又拖慢传输
前端如何发请求并渲染表格
每次点击页码，不是拼 DOM 字符串再 innerHTML =，而是清空 tbody 后用 insertRow() 或 document.createElement('tr') 动态插入，更安全也更易调试。
- 请求前给“下一页”按钮加
disabled，防止连点触发重复请求；响应回来再恢复 - 渲染前先执行
tbody.innerHTML = ''，别漏掉，否则旧数据会残留 - 滚动定位要加：翻页后执行
document.querySelector('tbody').scrollIntoView({ block: 'nearest' })，不然用户可能看不到新内容 - 错误处理不能省：网络失败时显示提示文案，
total为null或0时要兜底渲染空表格+提示“暂无数据”
分页控件点击事件常见失效原因
不是逻辑写错了，往往是状态没同步或事件绑定太糙。
立即学习“前端免费学习笔记（深入）”；
- “上一页”按钮在
currentPage === 1时，光靠 JS 判断跳过逻辑不行，必须加disabled属性 + 对应 CSS 灰色态，否则用户仍可点击 - 页码按钮用
for循环生成时，别用var i写闭包，推荐统一用data-page="2"，点击时取event.target.dataset.page - 移动端点击区域太小，按钮宽度至少
44px，否则误操作率高；别依赖:hover做交互反馈，它在触屏设备上无效
最常被忽略的是边界：total 返回 NaN、pageSize 被前端设成负数、page 传了字符串 "2" 却没 parseInt，这些都会让分页逻辑静默失败。真正在生产环境跑起来，得靠日志+前端校验+后端兜底三道防线。
