html分页仅是静态结构，数据加载由javascript或服务端控制；服务端分页适合大数据量，前端分页适合小数据量；需注意页码计算、参数传递、边界校验等关键逻辑。
HTML分页本身不加载数据，它只是静态的标签结构；真正决定数据怎么来、何时来、来多少的，是 JavaScript 请求逻辑或服务端渲染策略。
HTML分页标签（<nav></nav> + <ul class="pagination"></ul>）不做任何数据请求
纯 HTML 写出的分页链接，比如：
<nav><ul class="pagination">
<li><a href="?page=1">1</a></li>
<li><a href="?page=2">2</a></li>
</ul></nav>这类代码不会触发 AJAX，也不会自动 fetch 数据——它只生成可点击的 <a></a> 标签。点击后浏览器会整页跳转，是否刷新、加载哪部分数据，完全取决于 href 指向的后端路由行为。前端分页（JS 控制）必须手动处理数据加载时机和范围
如果用 fetch() 或 axios.get() 加载分页数据，关键不是“怎么画按钮”，而是“什么时候发请求”和“传什么参数”：
-
page和limit（或offset）必须同步传递给接口，否则后端无法返回对应页数据 - 首次加载需主动调用一次请求，不能等用户点“第2页”才开始拉数据
- 切换页码时，应禁用按钮或加 loading 状态，避免重复点击触发多次请求
- 若接口返回的是全量数据（如 100 条数组），前端分页只是 slice 显示，那
limit参数就无意义，且大数据量下会卡顿
服务端分页 vs 前端分页：数据加载方式决定性能瓶颈位置
区别不在 HTML 结构，而在数据获取路径：
- 服务端分页：每次点击都发新请求，后端查库 + 分页（如 MySQL
LIMIT offset, size），返回当前页数据 —— 适合数据量大、搜索条件复杂场景 - 前端分页：一次性加载全部数据（如 50 条），JS 在内存中按
currentPage * pageSize计算展示区间 —— 适合数据稳定、总量小、无需服务端过滤的列表 - 混用风险：前端渲染了 10 页按钮，但后端只返回第 1 页数据，又没做兜底逻辑，就会出现“能点第5页但没内容”
容易被忽略的加载边界问题
分页控件常被当成“UI 组件”直接复制粘贴，但以下细节不处理就会出错：
- 后端返回的
total字段为 0 或 null 时，Math.ceil(total / pageSize)会算出NaN或Infinity，导致页码栏异常 - 用户手动修改 URL 中的
page=999，而服务端未校验页码合法性（如最大页数），可能返回空数组或 404，前端没 catch 就白屏 - 滚动加载（infinite scroll）和传统页码按钮共存时，
IntersectionObserver触发时机与点击事件冲突，容易重复加载同一页
分页的“形”在 HTML，“魂”在数据流控制——按钮画得再准，数据没对齐、时机没卡住、边界没兜住，一样翻车。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
