HTML分页仅是外壳，数据加载取决于fetch调用、服务端渲染或分页参数正确性；常见错误包括静态链接跳转、page参数写死、前端切片假分页、并发请求未加锁及SEO的rel属性缺失。
HTML分页本身不加载数据，也不影响数据加载——它只是个链接或按钮的外壳。真正决定“有没有数据”“什么时候来”“来多少”的，是背后是否调用 fetch()、服务端是否渲染新 HTML，或者你有没有写错分页参数。
点击分页链接后没反应？先查是不是纯静态跳转
常见错误是把分页写成 @#@#@#@#@#@#@#@#@#@0，但 list.html 是个静态文件，压根没逻辑读取 page 参数。浏览器只是刷新页面，什么新数据都不会出来。
- 如果想靠前端控制，必须拦截默认跳转：
event.preventDefault()，再手动调用loadPage(2) - 如果想靠服务端，
list.html得是服务端模板（如 PHP/Node.js），且实际执行了带LIMIT和OFFSET的查询 - 检查 Network 面板：点第2页后，有没有发新请求？请求 URL 是不是带了正确参数？响应内容是不是你预期的数据？
前端分页时 page 参数写死，等于只看第1页
很多人复制示例代码，直接写 fetch('/api/items?page=1') 放在初始化里，后面点任何页码按钮都无效——因为请求根本没变。
- 页码必须动态传入：
function loadPage(pageNumber) { fetch(`/api/items?page=${pageNumber}`) } - 按钮点击时要显式调用：
button.addEventListener('click', () => loadPage(3))，不能只改href或data-page - 用户输入页码跳转时，记得校验：
Math.max(1, Math.min(totalPages, +input.value))，避免越界或 NaN - URL 中的
page值若来自不可信来源（比如 URL 参数），用encodeURIComponent()包一层更稳妥
服务端分页接口返回全部数据，前端切片 = 假分页
后端接口返回 1000 条数据，前端用 slice() 切出第 3 页的 10 条，看起来能翻页，实则埋雷：首屏加载慢、内存占用高、搜索排序失效、无法跳转到具体页码。
- 真分页要求后端 API 必须支持
page和per_page（或offset/limit）参数，并在数据库层做限制 - 接口应返回分页元信息：
total、page、per_page，否则前端算不出总页数，页码控件就只能硬写死 - 游标分页（
cursor或last_id）比页码分页更稳定，尤其在数据高频增删场景下，避免漏条或重复 - 别让前端自己算
offset = (page - 1) * per_page后传给后端——万一前后端 pageSize 不一致，页就对不上
上拉加载 / 点击加载更多时，状态管理最容易崩
没加锁、没判空、没清 loading，三秒内连点五次“加载更多”，结果发了五个并发请求，后端返回顺序乱、前端拼接错位、UI反复闪动。
- 必须设状态字段：
isFetching = true，请求开始前置为true，结束（无论成功失败）后重置为false - “还有更多”得靠后端返回的
has_more: true或next_offset !== null控制，不能靠前端猜page - 加载中提示要用固定高度占位块（如
），避免 DOM 插入导致滚动条跳动、误触发二次加载 - 移动端 iOS Safari 下
document.body.scrollTop经常为 0，优先用document.documentElement.scrollTop判断滚动位置
最常被忽略的是：分页控件里的 rel="next" 和 rel="prev" 标签，搜索引擎靠它理解页面关系。没加，第二页大概率不被收录；加了但 href 指向假地址或 404，反而损害 SEO。这个细节不在 JS 里，而在服务端生成的 HTML 中。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
