直接监听 scroll 易卡顿因触发频率过高导致重排重绘，应改用 IntersectionObserver 实现触底加载，配合 cursor 分页与 AbortController 避免状态混乱。
为什么直接监听 scroll 容易卡顿？
因为原生 scroll 事件触发频率极高（每毫秒都可能触发），若在回调里直接调用 fetch 或操作 DOM，浏览器会频繁重排重绘，导致掉帧。尤其在低端设备或列表项含图片/复杂样式时，scrollTop 检查 + appendChild 组合极易引发 Layout Thrashing。
关键不是“要不要监听”，而是“什么时候响应”。必须加节流或采用更稳定的检测方式：
- 用
IntersectionObserver替代scroll+ 手动计算 —— 它由浏览器原生调度，不阻塞主线程 - 若必须用
scroll，至少用requestIdleCallback或setTimeout(..., 0)延迟到空闲期执行加载逻辑 - 避免在滚动中反复读取
document.documentElement.scrollHeight和scrollTop，这些是强制同步布局的“脏读”
怎么用 IntersectionObserver 实现可靠触底加载？
它不依赖滚动位置数值，而是观察一个“占位元素”（sentinel）是否进入视口。只要它一出现，就说明该加载下一页了。这种方式对虚拟滚动、动态高度、甚至 CSS transform 位移都兼容。
注意三个易错点：
立即学习“Java免费学习笔记（深入）”；
-
rootMargin要设为类似"0px 0px 200px 0px"，提前 200px 触发，避免用户已看到空白才开始请求 - 观察器创建后，必须确保 sentinel 元素真实存在于 DOM 中；若用 React/Vue 动态渲染，需在节点挂载后再
observe() - 加载中要
unobserve(sentinel)，防止重复触发；新数据追加后，再observe()新的 sentinel
const observer = new IntersectionObserver(
(entries) => {
if (entries[0].isIntersecting && !loading) {
observer.unobserve(sentinel);
loadMore().finally(() => observer.observe(sentinel));
}
},
{ rootMargin: "0px 0px 200px 0px" }
);
observer.observe(sentinel);
长列表卡顿的真正瓶颈往往不在 JS，而在 DOM 节点数量
渲染 1 万条 <li>，哪怕内容为空，浏览器也要维护上万个 Layout Object。此时任何优化 JS 逻辑都是隔靴搔痒。必须做 DOM 节点复用（即“窗口化”）。
核心策略是只保留可视区域 ±1～2 屏的 DOM 节点，其余用 height 占位：
- 用
getBoundingClientRect()或scrollTop+ 容器高度算出当前应显示的起始索引 - 所有列表项用固定高度（或预估高度），通过
transform: translateY()定位，避免影响文档流 - 用
DocumentFragment批量更新，减少重排次数
如果业务允许，直接用成熟库如 react-window 或 vue-virtual-scroller，它们已处理好滚动精度、键盘导航、动态高度等边缘 case。
服务端分页参数和前端加载状态怎么对齐？
前端无限滚动常误用 page=1, page=2... 这类偏移式分页，导致翻页时插入新数据后，用户滚动位置突变、重复加载、或漏数据。正确做法是用游标（cursor）分页：
- 后端返回下一页的
cursor（例如最后一条记录的id或created_at时间戳） - 前端只存这个
cursor，下次请求带过去，不依赖页码或offset - 加载中状态必须绑定到具体 cursor 请求，避免用户快速滚动多次触发多并发请求，造成状态混乱
另外，AbortController 必须用上：每次新请求前 abort 上一个未完成的请求，否则旧请求返回后覆盖新数据，UI 就会“倒退”。
