分页加载应优先使用后端返回的 next_url 而非前端自增页码，避免逻辑不一致；需用 isloading 开关防重复请求，禁用节流/防抖；滚动到底部检测推荐 getboundingclientrect().bottom；数据合并注意解构层级，成功后及时清空 error 状态。
分页加载的核心判断：前端自己算页码，还是后端返回下一页地址
绝大多数初级项目用的是「页码+每页数量」模式，而不是游标分页。这意味着你必须维护 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 来判断。有些接口即使还有数据，最后一页也可能返回少于 <code>pageSize 条（比如总共 23 条，size=10，第三页就只有 3 条）。所以更稳妥的是后端返回 has_more: false 或 is_last_page: true 字段——前端优先信这个。
如果接口没提供这类字段，那就得靠客户端逻辑兜底：
- 记录已加载总条数，比如
loadedCount += newData.length，再和后端返回的total对比 - 连续两次请求返回空数组，就认为到底了（适合不返回 total 的老接口）
- 错误处理要区分网络错误（可重试）、业务错误（如 401、403）、空响应（可能是真没数据）——不同错误 UI 反馈方式不同
最常被忽略的是“加载失败后用户想重试”的入口。别只在控制台打个 log，至少放个“点击重试”的按钮，或者下拉刷新时自动重试。不然用户卡在空白页，只能手动刷新整个页面。
