IntersectionObserver实现懒加载与无限滚动的核心是提前适量加载：图片通过rootMargin预留缓冲区预加载，无限滚动用sentinel元素在临界点触发；需合理配置阈值、及时销毁监听、降级兼容并协调二者触发时机。
用 IntersectionObserver 做图片懒加载和无限滚动，核心不是“等它出现再加载”，而是“在用户真正需要前，提前一点点加载——不多不少，刚刚好”。关键在于合理设置 rootMargin 和监听粒度，避免卡顿、白屏或过早请求。
图片懒加载：只加载可见区 + 安全缓冲区的图片
不要等图片完全进入视口才加载，那样会有明显延迟或闪烁。利用 rootMargin 提前触发：
- 给
IntersectionObserver配置{ rootMargin: '200px' }，相当于在视口下方（及上下左右）扩展 200px 的检测区域，用户还没滑到，图片就已开始加载 - 为每个
<img>设置data-src存真实地址，src先留空或指向极小占位图（如data:image/svg+xml,...），避免默认请求 404 - 回调中判断
isIntersecting === true且图片未加载过（加个data-loaded="true"标记），再赋值img.src = img.dataset.src，并可选地移除监听（observer.unobserve(img)） - 对高密度列表（如瀑布流），可配合
threshold: [0.1, 0.5]，让 10% 或 50% 可见时分别触发不同逻辑（比如先占位、再高清）
无限滚动：在“快到底”时预加载下一页，而非“到底才动”
监听一个占位 <div id="sentinel"> 元素，把它放在当前数据末尾之后。不监听最后一条内容本身，避免频繁重计算和边界抖动：
- 每次插入新数据后，调用
observer.observe(sentinel)（如果之前已解绑需重新绑定） -
rootMargin设为'0px 0px 300px 0px'：仅向下扩展 300px，确保用户还有约半屏距离时就触发加载，体验顺滑 - 回调中检查
isIntersecting，为防重复触发，立即unobserve(sentinel)，待新数据渲染完成后再重新 observe - 加载中可禁用滚动监听或加 loading 状态，避免快速滚动导致多次并发请求
性能感知的关键细节：节流、销毁与降级
“性能感知”不是靠加功能，而是靠克制和兜底：
- 不用手动节流函数包裹回调——
IntersectionObserver本身是异步且浏览器原生优化的，但避免在回调里做重绘操作（如直接改大量 DOM），优先用requestIdleCallback或分片更新 - 页面卸载或组件销毁时，务必调用
observer.disconnect()，否则监听器持续驻留内存，尤其 SPA 中易引发内存泄漏 - 对不支持
IntersectionObserver的旧浏览器（如 IE），降级为 scroll + getBoundingClientRect 轮询，但加上throttle(100ms)和cancelAnimationFrame清理机制 - 移动端注意：Safari 旧版本对
rootMargin百分比支持不稳定，建议统一用 px 单位；iOS WebKit 中若页面有transform，可能影响根容器判定，此时显式传入root: null（即 viewport）更可靠
组合使用：懒加载 + 无限滚动共存时的注意事项
当列表项本身含图片，且列表又支持无限滚动，二者会叠加触发时机，需协调资源节奏：
- 无限滚动的 sentinel 应放在所有图片懒加载元素之后，确保它最后进入检测区，避免因图片加载慢而误判“已到末尾”
- 图片加载完成可触发
img.onload，但不要在此回调里直接调用无限滚动加载——应由 sentinel 主导，图片只是内容的一部分 - 网络较弱时，可动态调整
rootMargin：例如根据navigator.connection.effectiveType，从'300px'改为'600px'，换取更早加载机会 - 服务端支持时，首屏图片走同步 HTML 渲染，后续图片才走懒加载，既保障首屏速度，又减轻 JS 负担
不复杂但容易忽略。真正影响体验的，往往不是“能不能加载”，而是“什么时候加载、加载多少、失败怎么兜住”。IntersectionObserver 提供了精准的时机接口，剩下的，是根据场景做克制的决策。
