IntersectionObserver 怎样避免滚动监听抖动

滚动时出现“抖动”，通常不是 IntersectionObserver 自己在不停触发，而是旧代码把每一次 scroll 都变成了位置读取、状态写入和重复业务请求。解决思路是把“是否越过可见性边界”交给观察器，只在阈值发生变化时处理；回调内部再做轻量判断，完成一次任务后及时解除观察。

最小稳妥方案是：为目标元素创建一个复用的 IntersectionObserver，先用 threshold: 0 或少量阈值限制通知次数，再用 entry.isIntersecting 做方向判断；一次性加载或曝光任务完成后调用 unobserve()。不要把每个像素的滚动进度误当成 IntersectionObserver 的职责。

参考资料：https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API。以下示例是静态代码说明，重点放在触发边界和资源释放，不把配图当作浏览器运行截图。

先保护主线程帧预算：抖动往往从 scroll 监听开始

旧式写法常见于目录高亮、懒加载和曝光统计：在 scroll 回调里循环目标元素，再调用 getBoundingClientRect() 判断是否进入视口。问题不只是回调次数多，位置读取和后续 DOM 写入还可能互相打断，导致同一帧里重复做无效工作。

可以把这里的“资产”理解为一帧可用的主线程时间，把“攻击路径”理解为高频输入不断放大同步工作。若业务只需要知道元素进入或离开某个区域，就没有必要自行计算每一次像素变化。

把可见性边界交给 IntersectionObserver

IntersectionObserver 异步观察目标和视口或指定根元素的相交变化。root: null 表示浏览器视口；如果目标在一个滚动容器里，应把该容器设为根，并确保目标是它的后代。threshold 可以是单个数字或数组，代表目标可见比例跨过哪些边界时通知。

const cards = document.querySelectorAll('[data-lazy-card]');

const observer = new IntersectionObserver((entries, currentObserver) => {
  entries.forEach((entry) => {
    // 只处理进入观察范围的目标，离开时不重复触发加载任务。
    if (!entry.isIntersecting) return;

    const card = entry.target;
    // 真实项目里可在这里读取 data-src 并启动一次请求。
    card.classList.add('is-visible');

    // 一次性任务完成后解除观察，避免同一目标反复进入回调。
    currentObserver.unobserve(card);
  });
}, {
  root: null,
  // 提前 120px 通知，给图片或卡片准备留出缓冲区。
  rootMargin: '120px 0px',
  // 只关心“开始相交”这一条边界，避免使用过密数组。
  threshold: 0
});

cards.forEach((card) => observer.observe(card));

这里的关键控制点是阈值数量和观察对象生命周期。threshold: [0, 0.25, 0.5, 0.75, 1] 适合需要几个可见性阶段的场景；如果只是懒加载，通常一个进入边界就足够。rootMargin 是观察区域的扩展或收缩，不是延迟时间，也不会替你完成网络请求。

风险分级：回调要短，阈值不要伪装成进度条

观察器降低了自行计算相交关系的成本，但回调仍在主线程执行。回调里应优先完成状态标记、派发小事件或启动异步任务，不要同步遍历大树、反复测量布局或立刻渲染大量节点。若需要记录曝光次数，还要按业务 ID 去重，而不是假定每个 entry 都代表一次全新曝光。

const seen = new Set();

const exposureObserver = new IntersectionObserver((entries, observer) => {
  for (const entry of entries) {
    // 只接受越过进入边界的目标，避免离开时重复记账。
    if (!entry.isIntersecting) continue;

    const id = entry.target.dataset.itemId;
    // 用业务 ID 去重，防止同一元素因布局变化重复处理。
    if (!id || seen.has(id)) continue;
    seen.add(id);

    // 回调保持短小；较重的统计或渲染应转给异步调度。
    queueMicrotask(() => sendExposureEvent({ id }));
    observer.unobserve(entry.target);
  }
}, {
  threshold: 0.5
});

如果你需要“每一帧都知道元素移动了多少像素”，那是另一类需求，IntersectionObserver 并不提供精确像素重叠数量。不要用上百个阈值模拟动画进度；这样会扩大通知面，反而重新制造频繁处理。

审计记录与验证清单：确认是边界问题而非盲目加节流

排查抖动时可以临时记录 entry.target、entry.isIntersecting、entry.intersectionRatio 和 entry.time，观察到底是阈值太密、根元素选错，还是业务代码重复注册了多个观察器。记录只用于开发排查，不要在生产日志中写入用户敏感信息。

如果组件整体销毁，应调用 disconnect() 清理观察器；如果只是某个一次性目标完成，应调用 unobserve(target)。这两个动作的范围不同，前者会停止当前观察器的全部目标，后者只移除一个目标。

相关问题

为什么用了 IntersectionObserver 仍然感觉回调很多？

先检查 threshold 是否过密、目标是否在边界附近反复进出，以及页面是否创建了多个 observer。然后确认回调内部没有重复注册事件或同步执行重任务。

rootMargin 能不能替代防抖？

不能。rootMargin 改变观察区域，防抖或节流改变业务处理频率；两者解决的问题不同。一次性观察任务优先用合适阈值和 unobserve()。

什么时候仍然需要 scroll 事件？

需要连续像素位置、滚动速度或复杂手势进度时，scroll 事件仍可能合适，但应配合合理的调度和批量读取。只需要进入、离开或达到几个可见比例时，优先考虑 IntersectionObserver。