IntersectionObserver trackVisibility 为什么需要 delay

trackVisibility 开启后，IntersectionObserver 判断的就不只是“元素有没有进入 root”，还会考虑遮挡、透明度、滤镜和变换等视觉状态。这个判断比普通相交计算更昂贵，所以 delay 用来限制两次可见性通知之间的最短间隔。实践中应把它设置为业务能接受的最大值；当 trackVisibility: true 时，浏览器会把小于 100 毫秒或未设置的值按至少 100 毫秒处理。

官方文档地址：https://developer.mozilla.org/en-US/docs/Web/API/IntersectionObserver/trackVisibility

trackVisibility 解决的不是普通相交问题

没有开启可见性跟踪时，浏览器主要回答“目标元素的几何区域是否与 root 的可视区域相交”。但元素可能被另一个层覆盖，也可能因为透明度、滤镜或变换而不适合被当作真正可见。trackVisibility 会把这些视觉条件纳入判断，而且判断策略偏保守：即使开发者认为元素仍然可见，浏览器也可能因为轻微的透明度变化而不报告它。

因此它更适合广告可见性、曝光统计或需要区分“进入区域”和“实际可见”的场景。只要任务是图片懒加载、列表预取或触底加载，普通的 IntersectionObserver 通常更轻量。

delay 怎样限制可见性计算的通知频率

可见性计算并不是普通回调的简单排队。开启 trackVisibility 后，浏览器要重复评估目标是否被覆盖、是否有影响可见性的样式，因此 MDN 建议把 delay 设为业务允许的最大值。下面的配置用 250 毫秒作为示例，重点是让回调不会比这个间隔更频繁地收到可见性通知：

const observer = new IntersectionObserver((entries) => {
  // 一次回调可能包含多个目标或多个阈值产生的 entries。
  for (const entry of entries) {
    // isIntersecting 只表达相交；isVisible 才反映可见性跟踪结果。
    if (entry.isIntersecting && entry.isVisible) {
      console.log('目标满足可见性条件', entry.target);
    }
  }
}, {
  // 开启昂贵的视觉判断，适合曝光统计等确有需要的场景。
  trackVisibility: true,
  // 最小通知间隔不能低于 100ms；250ms 可降低通知压力。
  delay: 250,
  // 只有可见比例达到 50% 时才关注这个状态变化。
  threshold: 0.5
});

// 观察目标元素；不需要时应解除观察，避免继续持有引用。
observer.observe(document.querySelector('[data-ad]'));

这里的 delay 不是把回调函数做一次传统的 debounce。它是观察器配置的一部分，用来限制可见性通知的最短周期；回调仍可能收到多个 entries，不能把每次调用当成只有一个目标。

配置时要同时看 delay、threshold 和兼容性

当 trackVisibility 为 true 时，delay 小于 100 毫秒会被提升到 100 毫秒；不设置也不能得到“零间隔的精确可见性”。如果曝光统计允许四分之一秒的误差，就直接使用 250 毫秒或更高值；如果业务要求更快反馈，应先重新评估是否真的需要视觉可见性跟踪，而不是把 delay 写得很小。

threshold 负责可见比例阈值，delay 负责通知间隔，两者解决的是不同问题。还要注意 trackVisibility 并非所有主流浏览器都支持，且在 MDN 上标为实验性能力。生产代码应准备能力检测或降级路径，例如未提供 entry.isVisible 时只使用普通相交结果，并把“普通相交”和“真实可见”区分记录。

常见问题

delay 能不能设置成 0？

普通观察器的默认值是 0，但开启 trackVisibility 后，浏览器要求最小值为 100 毫秒；小于这个值或未设置时会按 100 毫秒处理。

只做图片懒加载也要开启 trackVisibility 吗？

通常不需要。图片懒加载主要关心是否接近或进入 root，普通相交观察已经足够；只有业务确实要排除遮挡、透明度等情况时才考虑额外的可见性计算。