根本原因是分页状态管理不当，如page未递增、数据直接push导致重复，或快速连点引发并发请求错乱；应使用受控currentpage、禁用按钮、数组解构合并、fragment批量插入、依据后端has_more控制按钮显隐，并用intersectionobserver监听末尾元素触发加载。
点击加载更多时数据重复或错乱
根本原因是没正确管理分页状态，比如 page 变量在多次点击后未递增，或接口返回的数据直接 push 到已有数组而没做去重。更隐蔽的问题是：用户快速连点，触发了多个并发请求，后发先至导致 DOM 渲染顺序错乱。
实操建议：
- 用一个受控的
currentPage变量（初始为1），每次成功加载后才执行currentPage++ - 禁用按钮直到请求完成：
button.disabled = true，响应成功/失败后再恢复 - 不直接操作原始数组，改用
newData = [...existingData, ...fetchedItems]替代existingData.push(...) - 如果后端支持，加个防抖逻辑（如 300ms 内重复点击忽略），但优先靠服务端幂等 + 前端状态锁
fetch 后追加 DOM 而不是重绘整个列表
重渲染整个列表会丢失滚动位置、焦点、已展开的详情行，且性能差。必须只把新数据生成的 <li> 插入到底部。
实操建议：
- 用
document.createDocumentFragment()批量创建节点，再一次性append()到容器，避免反复触发重排 - 不要用
innerHTML += ...—— 它会销毁并重建所有子节点，包括已绑定的事件监听器 - 示例关键片段：
const frag = document.createDocumentFragment(); data.forEach(item => { const li = document.createElement('li'); li.innerHTML = `<span>${item.title}</span>`; frag.appendChild(li); }); listContainer.appendChild(frag);
如何判断是否还有下一页（无数据时隐藏按钮）
不能只看「本次请求返回 0 条」就禁用按钮——可能是网络错误或空数据合法场景。可靠依据是后端返回的分页元信息，比如 has_next、total_pages 或 next_cursor。
实操建议：
- 后端响应结构尽量包含明确字段，例如：
{ data: [...], pagination: { has_more: true, next_page: 3 } } - 前端拿到响应后，用
response.pagination.has_more === false控制按钮显隐，而非依赖data.length === 0 - 首次加载后若
has_more为false，直接loadMoreBtn.style.display = 'none' - 请求失败时，应保留按钮可点，并给出提示（如 toast），而不是静默禁用
滚动到底部自动触发加载的兼容写法
原生 IntersectionObserver 是首选，但老版本 Safari 对 rootMargin 支持不稳定；scroll 事件易误触且需手动节流。
实操建议：
- 用
IntersectionObserver观察一个占位<div id="sentinel"> 元素（放在列表末尾）：<pre class="brush:php;toolbar:false;">const observer = new IntersectionObserver( ([entry]) => { if (entry.isIntersecting) loadMore(); }, { rootMargin: '0px 0px -50px 0px' } // 提前 50px 触发 );</pre> <li>每次追加内容后，确保重新 <code>observer.observe(sentinel)（因为旧节点被移除） - 降级方案：监听
window.onscroll，通过sentinel.getBoundingClientRect().top 判断是否进入视口，但务必加 <code>requestIdleCallback或setTimeout(..., 0)节流
实际中最容易被忽略的是：加载中状态与按钮 UI 的同步粒度。比如按钮文字从「加载更多」变成「加载中…」，但用户取消网络请求后没还原；或者移动端 touchstart/touchend 与 click 事件冲突导致误触发两次。这些细节比分页逻辑本身更容易引发线上问题。
