HTML分页仅为静态链接，数据加载取决于背后请求方式；服务端分页首屏快但需刷新，前端分页交互流畅但首屏可能为空；真分页需后端支持page参数并分页查库，假分页前端切全部数据易卡顿；无限滚动非分页替代，适合信息流但不利SEO和跳转；rel="next/prev"对SEO关键，须服务端渲染且href真实有效；数据边界一致性是分页核心难点。
HTML分页本身不加载数据，但常被误当成“加载机制”
HTML分页（比如用 <nav> + <a href="?page=2">）只是静态链接，不主动请求数据。真正影响加载的，是它背后触发的请求方式：服务端渲染整页（同步刷新）、AJAX拉取片段、还是前端 JS 渲染 JSON 数据。很多人一看到“第2页”就以为浏览器在“分页时加载了数据”，其实只是点击链接后发起了一次新请求——和分页标签无关，和请求策略强相关。
服务端分页 vs 前端分页对首屏和后续加载的影响差异极大
服务端分页（如 PHP/Node.js 每次返回完整 HTML）首屏快、SEO 友好，但翻页必刷新，带宽压力集中在 HTML 体积；前端分页（如 React + fetch('/api/items?page=3')）交互流畅，但首屏可能空或需额外加载 JS，且若一次性把全部数据塞进前端再分页，内存和解析开销会陡增。
- 服务端分页：每次只查当前页数据（
OFFSET 20 LIMIT 10），数据库压力小，但 HTML 重复内容多 - 前端分页（真分页）：API 必须支持
page和per_page参数，且后端仍要分页查库，否则就是假分页 - 前端分页（假分页）：API 返回全部 1000 条，前端用
slice()切，滚动/跳页无网络请求，但首屏 JSON 大、JS 解析慢、移动端易卡顿
“无限滚动”不是分页替代方案，而是不同交互范式
无限滚动（IntersectionObserver 监听底部 + fetch 加载下一页）看起来更现代，但带来新问题：无法直接跳转到第 42 页、浏览器前进/后退失效、SEO 几乎为零、用户想回看前面内容得反复滚动。它适合信息流场景（如微博、小红书），不适合需要精确页码、导出、筛选或审计的业务（如后台订单列表）。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 如果产品要求支持 URL 分享（如
/orders?page=7），无限滚动就得退化成带 hash 或 URL state 的混合模式 - 用
scroll event而非IntersectionObserver容易触发高频请求，建议加节流或防抖（如setTimeout延迟 100ms） - 服务端必须返回
total_count或has_next字段，否则前端不知道该不该继续加载
分页控件里的 rel="next" 和 rel="prev" 对 SEO 很关键但常被忽略
搜索引擎靠这些 link 标签理解页面关系。没有它们，第二页很可能不被收录，或被当成独立无关页面。不是加了就行，必须严格匹配当前页逻辑：
立即学习“前端免费学习笔记（深入）”；
- 第 1 页只需
<link rel="next" href="/list?page=2"> - 第 5 页（共 10 页）要同时有
prev和next，href 必须真实可访问 - href 值不能带 session ID、UTM 参数等动态垃圾，否则会被视为不同 URL 重复内容
- 服务端渲染时生成，不要靠 JS 注入——爬虫不执行 JS
分页真正的复杂点不在 UI，而在数据边界一致性：API 返回的总条数、当前页码、每页数量，三者要在前后端对齐；否则用户点“最后一页”却 404，或页码显示错位，都是参数没对齐的锅。
