IntersectionObserver 替代 scroll 事件可避免卡顿丢帧，需用占位节点、rootMargin 提前触发、isIntersecting 双重校验，配合 documentFragment 批量插入、显式管理加载状态与终止条件。
用 IntersectionObserver 替代 scroll 事件监听
直接绑定 window.addEventListener('scroll') 是性能陷阱：每帧都可能触发，尤其在低端设备或复杂页面上，容易卡顿甚至丢帧。IntersectionObserver 不走主线程、不触发重排，语义也更准确——你不是在“监听滚动”，而是在“观察某个元素是否进入视口”。
实操要点：
- 在列表末尾插入一个占位节点：
<div id="sentinel"></div> - 创建 observer 时设
rootMargin: '200px'（提前 200px 触发），避免用户拉到底才动 - 必须用
entries[0].isIntersecting === true做双重校验，防止回调被缓存或误触发 - 移动端需确保容器有明确高度和
overflow-y: auto，否则 observer 可能失效（body 滚动时 root 默认是 document，但很多 UI 框架会改用局部容器）
rootMargin 和 isIntersecting 的典型配置误区
rootMargin: '0px 0px 200px 0px' 不是可选参数，它是缓冲关键。只写 '200px' 或漏掉单位会导致浏览器解析失败，回调永不触发；设成负值（如 '-100px'）则可能过早加载，浪费请求。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 滚动到底部后反复触发多次加载 → 没检查
isIntersecting就执行逻辑 - 新内容插入后，下一次滚动不再触发 → 忘了在加载完成后调用
observer.observe(sentinel) - iOS Safari 上完全无响应 → 容器缺少
height或overflow-y: auto，observer 失效
DOM 插入必须批量且锚定滚动位置
用 innerHTML += htmlString 看似省事，但每次都会触发完整 HTML 解析 + DOM 重建 + 重排，列表超过 200 条时性能断崖下跌；更糟的是，iOS Safari 在键盘弹起后恢复滚动时，会因 DOM 重置导致跳屏。
正确做法：
- 用
documentFragment批量挂载新节点，再一次性append()到容器 - 所有列表项必须有明确高度：用
height、min-height或CSS aspect-ratio，禁用height: auto且子元素浮动/绝对定位 - 插入后不手动调整
scrollTop，靠浏览器自然滚动延续；若需维持视觉位置，应在插入前记录sentinel.getBoundingClientRect().top，插入后补偿偏移
加载状态与终止条件必须显式管理
无限滚动最常崩在“以为后端返回空数组就该停”，结果网络错误、游标失效、分页越界都返回空，前端却继续死循环请求。hasMore 不是可选字段，是协议契约。
关键判断要分层：
-
fetch抛异常 → 重试最多 1 次，之后设loading = false并显示“点击重试”按钮 - 响应成功但
response.data.length === 0或response.hasMore === false→ 立即observer.unobserve(sentinel)，移除监听 - 游标字段（如
next_cursor）为null或空字符串 → 同上，视为终点 - 任何一次加载失败后，
loading必须恢复为false，否则后续滚动永远被锁死
最易被忽略的点是：observer 实例复用时，没在新内容插入后重新调用 observe()，导致监听静默失效；以及容器未设固定高度时，在局部滚动场景下 observer 根本无法工作。
