分页加载实现方法详解

本文深入剖析了初级项目中分页加载的实战要点与常见陷阱，强调应优先采用后端返回的 next_url 进行下一页请求以规避前后端页码逻辑不一致的风险，同时通过 isLoading 开关而非节流防抖来可靠防止重复请求；推荐使用 getBoundingClientRect().bottom 精准判断滚动到底部，并详解数据合并时的解构层级、错误状态及时清空、以及“无更多数据”和失败重试的合理 UI 收尾策略——这些看似细节的处理，恰恰是保障分页体验流畅、稳定、用户友好的关键所在。

分页加载的核心判断：前端自己算页码，还是后端返回下一页地址

绝大多数初级项目用的是「页码+每页数量」模式，而不是游标分页。这意味着你必须维护 currentPage 和 pageSize 两个状态，每次请求都拼上 ?page=2&size=10 这类参数。后端如果返回了 next_url 字段（比如 JSON 里带 "next": "/api/items?page=3&size=10"），那就别自己算页码了——直接拿那个 URL 发请求，更可靠，也避免前后端页码逻辑不一致。

常见错误是前端硬编码 currentPage++，但后端实际返回的总页数可能小于预期（比如删了数据），结果点到第 6 页时接口返回空数组，UI 却还在显示“加载中”。建议每次响应后检查 data.length === 0 且 currentPage > 1，就停掉自动加载。

滚动到底部触发加载时，如何防重复请求

监听 window.onscroll 或 IntersectionObserver 都行，但关键不是“怎么监听”，而是“怎么锁住请求”。最简单有效的方式是加一个开关变量：isLoading，在发起请求前设为 true，成功或失败后设回 false。千万别只靠节流（throttle）或防抖（debounce）——它们解决的是高频触发，不是并发请求。

• 用 IntersectionObserver 更稳妥，尤其在移动端；onscroll 在 iOS Safari 上容易漏触发
• 判断是否“到底部”别用 scrollTop + clientHeight >= scrollHeight，误差大；改用 target.getBoundingClientRect().bottom （+50 是提前加载缓冲）
• 加载中状态要透出给用户，哪怕只是禁用按钮或加个 loading 指示器；否则用户狂点，isLoading 一漏设，就发出去五六个重复请求

React/Vue 里更新列表数据的正确姿势：concat 还是 spread？

分页加载是追加数据，不是替换，所以别写 setData(newData)。该用 setData(prev => [...prev, ...newData])（React）或 this.list.push(...newData)（Vue 2）或 list.value = [...list.value, ...newData]（Vue 3）。注意：如果后端返回的数据结构带 data 字段（比如 { code: 0, data: [...] }），别忘了取 res.data.data，初级项目最容易在这里解构错一层。

另一个坑是没清空错误状态。比如第一次加载失败，显示了错误提示，第二次成功加载后，如果没手动清除 error 状态，UI 上错误提示还挂着。更新数据时，顺手把 error 设为 null 或 undefined。

接口报错或无更多数据时，UI 该怎么收尾

“没有更多了”不能只靠后端返回 total === 0 或 data.length 来判断。有些接口即使还有数据，最后一页也可能返回少于 pageSize 条（比如总共 23 条，size=10，第三页就只有 3 条）。所以更稳妥的是后端返回 has_more: false 或 is_last_page: true 字段——前端优先信这个。

如果接口没提供这类字段，那就得靠客户端逻辑兜底：

• 记录已加载总条数，比如 loadedCount += newData.length，再和后端返回的 total 对比
• 连续两次请求返回空数组，就认为到底了（适合不返回 total 的老接口）
• 错误处理要区分网络错误（可重试）、业务错误（如 401、403）、空响应（可能是真没数据）——不同错误 UI 反馈方式不同

最常被忽略的是“加载失败后用户想重试”的入口。别只在控制台打个 log，至少放个“点击重试”的按钮，或者下拉刷新时自动重试。不然用户卡在空白页，只能手动刷新整个页面。

今天关于《分页加载实现方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！