IntersectionObserver 实战：曝光埋点、预加载与滚动性能优化

刚接手那会儿，我在内容型App上做了一个信息流曝光打点需求。第一版为了省事直接用 scroll 监听加 getBoundingClientRect 判断卡片是否进入屏幕，结果在低端安卓上越滑越卡，滚动阴影肉眼可见地粘滞，最后定位出来是主线程被大量的布局计算拖垮了。后来换成 IntersectionObserver，打点逻辑不变，性能问题直接消失，代码量还减了一半。这篇文章不是基础科普，而是把 IntersectionObserver 放回真实场景里，聊预加载调参、曝光埋点、阅读进度追踪、工程封装和兼容降级这些实操层面的事。

IntersectionObserver 的核心是它把一个高频的“滚动位置判断”变成了浏览器底层异步维护的“交叉状态通知”，如果你只是停留在 threshold: 0、进入可视区就加载这种入门用法，很多边界问题会在线上慢慢暴露出来。下面这些内容和踩坑记录，是后面几个项目里反复验证过的方案，照着用能少走不少弯路。

1. 理解它的异步模型，是一切高级玩法的基础

1.1 IO 不是“滚动事件”，而是一套状态同步机制

很多人初学 IntersectionObserver 时，会下意识把它和 scroll 事件放在同一个心智模型里：以为滚动一下就会触发一次回调，像事件那样高频且连续。这个理解是错的。IntersectionObserver 本质上是一个异步状态同步机制：当目标元素与根元素（通常是视口）的交叉情况发生变化时，浏览器才会批量把新的交叉状态推送给你的回调，而不是每滚动几像素就触发一次。

它更接近“状态机”而非“事件流”。元素的交叉状态只有两种：交叠（isIntersecting 为 true）和不交叠（false），而交叉的具体程度用 intersectionRatio（0 到 1 之间的小数）表示。当元素位置发生变化时，浏览器会在渲染帧的合适时机重新计算交叉区域，如果新状态和上一次状态不同，并且状态变化跨过了你配置的阈值（threshold），才会触发回调。

这也是为什么使用 IO 之后页面滚动会平滑很多。scroll 事件一秒钟能触发几十上百次，即使你在回调里做了防抖或 requestAnimationFrame 节流，也依然避不开每次都强制浏览器进行布局读取；而 IO 由浏览器统一调度，它在“应该检查的时候”检查，在“应该通知的时候”通知，你的 JavaScript 主线程几乎零负担。

1.2 忽略首次回调，是绝大多数逻辑误判的来源

IntersectionObserver 有一个很容易被忽略的规则：当调用 observe(target) 后，浏览器会异步地主动触发一次回调，无论目标此刻是否真的在可视区内。这个设计初衷是让开发者拿到初始交叉状态，避免“先假设不可见，等滚动后再纠正”的尴尬。

但在我看过的大量业务代码里，这个首次回调经常导致埋点或懒加载的逻辑误判。举个例子：某个图片懒加载实现，判断 entry.isIntersecting === true 就加载图片。在页面初始化时，如果第一个屏幕里的图片恰好被 observe，第一次回调就会携带 isIntersecting: true，没问题，图片被正确加载。但如果你在回调里做的是“从不可见变成可见才上报曝光”，首次回调如果可见，它其实不是一次真正的“用户滚动进入”，而是状态初始化，逻辑上不应该算一次曝光。

处理办法有两个方向：一是判断 entry.isIntersecting 和上一次记录的状态，只有发生“false -> true”的状态翻转才处理；二是在初始化标记下跳过首次回调。后面在曝光埋点章节我会给出完整示例。这个细节不解决，出来的数据会忽高忽低，排查起来很费劲。

2. 善用 rootMargin 和 threshold，能做出普通监听做不到的事

2.1 负值 rootMargin：做一个真正的“预加载区”

rootMargin 是用来“放大”或“缩小”根元素可观测矩形的属性，很多人只拿它做正值来实现预加载（图片提前 200px 进入视野就加载），但负值的使用其实更容易被忽视。

举一个非常常见的需求：平台资讯详情页底部会有一个“推荐阅读”区域，产品希望统计用户是否真的拉到了页面最底部，而不是只看 scrollTop 是否接近底部。因为滚动到底部时，用户可能只是快速滑过，或者手指惯性滑动导致误触，读取 scrollTop 很容易把“到达过底部”和“认真看完了最后一段内容”混为一谈。

我的做法是把文末的“看完啦”标记元素作为观察目标，设置：

javascript复制const observer = new IntersectionObserver(callback, {
  rootMargin: '0px 0px -20% 0px',
  threshold: [0]
});

这里 rootMargin 的底部被缩小了 20%，相当于把可视区的底部边界向上抬高了 20%。目标元素必须真正进入可视区的“下半区以上”，也就是越过了这个收缩后的底部边界，回调才会触发。用户只是滑动到接近底部但还没读到最后一屏时，是达不到触发条件的。这就是负 rootMargin 的典型玩法。

类似的场景还有“回到顶部按钮”，很多人希望在用户下滑超过一屏后显示按钮，用负的 rootMargin: '-100% 0px 0px 0px 观察一个顶部占位元素，向下滚到元素离开显示区域后，回调自然就会触发，完全不需要自己去算 scrollTop。用 IO 的思维是“描述目标状态”，而不是“监听某个数字的区间变化”，代码写起来会直观很多。

2.2 threshold 的直觉误区：大元素永远达不到高比例

threshold 表示交叉比例触发的阈值，可以传一个数组，例如 [0, 0.25, 0.5, 0.75, 1]。这个比例的计算方式是：目标元素与根元素的交叉面积 ÷ 目标元素的总面积。这里有一个隐藏的坑：当目标元素比视口还高时，无论你怎么滚动，交叉面积都不可能超过视口面积，intersectionRatio 永远到不了 1。

比如文章正文的某个长图，它的高度是屏幕的三倍，用户把它完整滑过屏幕时，任何一瞬间可见部分占该元素总面积的比例都只有三分之一左右，intersectionRatio 最大也就约 0.33。如果你设置了 threshold: [0.5]，并指望达到 50% 可见才触发，这个回调可能永远都不会触发。

如果需求是“元素露出一部分就算曝光”，阈值设成 0 就行，配合 isIntersecting 判断。如果需求是“元素被看了超过一半才算曝光”，对小元素用 threshold: [0.5] 是合理的，但大元素的判断条件就该调整为“可见累计时长”或“元素边界与视口底部相交”，而不是死磕 ratio。理解这个计算口径，比死记 API 参数重要得多。

2.3 嵌套滚动容器场景，root 必须认真选择

根元素不传时，默认是浏览器视口（viewport）。但在移动端 H5 或 Web 后台管理系统里，很多内容的滚动并不发生在视口层，而是在某个具体的 overflow: auto 的容器内。这种场景如果依然使用默认 root，实际滚动的容器内部元素与视口的交叉关系并不会随容器内部滚动改变，回调永远不触发。

判断根元素应该选谁，有一个简单的经验方法：不是看 DOM 结构上离得多近，而是看哪个祖先元素真正产生了滚动。你可以从目标元素的 parentElement 开始向上遍历，逐个检查 scrollHeight > clientHeight，第一个满足条件的元素就是实际的滚动容器，它就是 root 的最佳候选。

代码上看，候选元素如果是滚动容器：

javascript复制const container = document.querySelector('.article-list__scroll-area');
const observer = new IntersectionObserver(callback, {
  root: container,
});

注意一个细节：当 root 不是视口时，rootMargin 也依然生效，而且是以这个滚动容器的内容区域为基准进行扩展或收缩的。如果容器内部还有固定头部或底部吸底组件，可以用正负 margin 来避开遮挡区域，做到真正“精确曝光”。

3. 场景实战：曝光埋点和阅读质量追踪

3.1 曝光一次与每次可见都要上报，是两条完全不同的代码路径

互联网内容产品的埋点里，“曝光”的定义通常不完全一致。有的场景要求“用户看到一次就算曝光，重复上下滑动不叠加”，比如品牌广告位；有的场景要求“每次从不可见变为可见都算一次曝光”，比如信息流里不同位置的卡片。

如果是“一次曝光”，最直接的思路是在命中后立即 unobserve(target)，这样后续怎么滚动都不会再触发。但这样有一个副作用：如果用户第一次只看到 1 像素，也算曝光；产品如果要求“看到 50% 以上才算有效曝光”，你还需要额外判断状态。更稳妥的一次性曝光方案是这样的：

javascript复制const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      sendExposureLog(entry.target.dataset.id);
      observer.unobserve(entry.target);
    }
  });
}, { threshold: [0.1] });

如果要求“多次可见都要上报”，则不能 unobserve，而是记录上一次状态，只在状态翻转时上报：

javascript复制const prevVisibleMap = new WeakMap();

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    const prev = prevVisibleMap.get(entry.target) || false;
    if (!prev && entry.isIntersecting) {
      sendExposureLog(entry.target.dataset.id);
    }
    prevVisibleMap.set(entry.target, entry.isIntersecting);
  });
}, { threshold: [0] });

用 WeakMap 记录状态是因为它不会阻止目标元素被垃圾回收，非常适合这种“列表动态增删”的场景。

3.2 “真曝光”识别：可见区域、停留时长、页面状态一起判断

单纯判断交叉状态，会把很多无效场景算进曝光：用户快速划过列表，卡片在屏幕上停留不到 100ms；或者用户在系统通知栏下拉，页面被短暂遮挡后又恢复。这时候曝光数据里的水分就会很高，运营看到的点击率、转化率都会失真。

真实项目里我习惯做两层过滤。第一层用 IO 判断交叉状态，第二层用定时器判断停留时长：元素进入可视且 document.visibilityState === 'visible' 时，启动一个 500ms 的定时器，如果时间达到且元素依然可见，再上报曝光；如果期间元素退出可视或页面切到后台，清除定时器，下次重新进入再重新计时。

javascript复制const exposureTimers = new Map();

function handleEntry(entry) {
  const el = entry.target;
  const existed = exposureTimers.has(el);

  if (!entry.isIntersecting || document.visibilityState !== 'visible') {
    if (existed) {
      clearTimeout(exposureTimers.get(el));
      exposureTimers.delete(el);
    }
    return;
  }

  if (!existed) {
    const timer = setTimeout(() => {
      sendExposureLog(el.dataset.id);
      exposureTimers.delete(el);
    }, 500);
    exposureTimers.set(el, timer);
  }
}

这个方案实现不复杂，但过滤效果非常明显，尤其在“短滑”和“下拉通知栏”这两个高频场景里，能少报将近三分之一的无效曝光。细节在于定时器不能用 setTimeout 永久挂在 Map 里，目标元素被销毁或 DOM 被替换时要主动清理。

3.3 上报可靠性：用 sendBeacon 兜底页面退出场景

曝光数据通常不要求 100% 精确，但损失太多会影响分析。页面滚动过程中，曝光回调可能成批触发（比如一次快速滑动让十几个卡片先后进入可视区），如果每个都立刻发一个 XHR，既浪费请求，又可能在用户快速切走时丢掉大部分数据。

我的做法是做一个上报队列，先攒在数组里，再用 requestIdleCallback 或每 2 秒批量发送一次。为了避免页面关闭瞬间数据丢失，用 navigator.sendBeacon 远比在 beforeunload 里调 XHR 可靠：

javascript复制const pendingEvents = [];

function sendExposureLog(data) {
  pendingEvents.push(data);
  scheduleFlush();
}

let flushId = null;
function scheduleFlush() {
  if (flushId) return;
  flushId = requestIdleCallback(() => {
    flush();
    flushId = null;
  }, { timeout: 2000 });
}

function flush() {
  const events = pendingEvents.slice();
  pendingEvents.length = 0;
  if (events.length && navigator.sendBeacon) {
    const body = new Blob([JSON.stringify({ events })], { type: 'application/json' });
    navigator.sendBeacon('/api/log', body);
  }
}

这一段也是我推荐的“高级用法”组合拳：IO 负责精确判断“什么时候该触发”，队列负责控制“触发之后数据怎么走”。两者是不同层面的事，但合起来才是生产可用的曝光系统。

4. 工程化实践：共享 Observer 与管理回调

4.1 一个页面只创建一个 Observer，尽量不要乱 new

IntersectionObserver 不是特别昂贵的对象，但如果你在 React 的每个组件里都 useEffect(() => new IntersectionObserver(...))，列表页几百个卡片就会创建几百个实例，这显然不是合理的资源利用。

浏览器官方推荐的做法是多个目标元素共享同一个 observer 实例，因为每个 observer 内部会对所有 observe 的目标统一做交叉计算，这样能显著减少重复计算。但实际开发里不同组件的回调逻辑不一样，共享一个实例就需要做回调分发。

我常用的工具类思路是用一个 Map 缓存 observer 实例，Map 的 key 是“由 root、rootMargin、threshold 组合成的唯一标识”，value 是对应的 observer。当业务组件需要使用某个配置的 observer 时，从 Map 里取，取不到再创建：

javascript复制const observerCache = new Map();

function getSharedObserver(options) {
  const key = JSON.stringify(options);
  if (!observerCache.has(key)) {
    const observer = new IntersectionObserver((entries) => {
      entries.forEach((entry) => {
        const callbacks = entry.target.__io_callbacks || [];
        callbacks.forEach((cb) => cb(entry));
      });
    }, options);
    observerCache.set(key, observer);
  }
  return observerCache.get(key);
}

function observeElement(el, options, callback) {
  const observer = getSharedObserver(options);
  el.__io_callbacks = el.__io_callbacks || [];
  el.__io_callbacks.push(callback);
  observer.observe(el);

  return () => {
    el.__io_callbacks = el.__io_callbacks.filter((cb) => cb !== callback);
    if (!el.__io_callbacks.length) observer.unobserve(el);
  };
}

通过把回调挂在目标元素的属性上，IO 回调只触发一次，所有关心该元素的模块都能收到通知。观察者和被观察者都得到了复用，组件卸载时再用返回的清理函数解除自己那一份监听，不会影响其它模块。

4.2 Vue 自定义指令、React Hook 的封装落地

在工程上，直接用工具函数还是有点“手写感”。我偏好做一层业务向封装。Vue 里自定义指令是干扰最小、心智最顺的形态：

javascript复制const vVisible = {
  mounted(el, binding) {
    const { handler, options = { threshold: 0 } } = binding.value || {};
    el.__unobserve = observeElement(el, options, (entry) => {
      if (entry.isIntersecting) handler(el, entry);
    });
  },
  unmounted(el) {
    el.__unobserve && el.__unobserve();
  },
};

使用时目标清晰：

html复制<div v-visible="{ handler: onCardExposure, options: { threshold: 0.2 } }"></div>

React 版封装会多用一点代码，因为需要处理 effect 的依存关系。我的 useInView Hook 回到一个 boolean 值，业务组件只需要关心「这个元素现在可不可见」：

javascript复制function useInView(options = {}) {
  const ref = useRef(null);
  const [inView, setInView] = useState(false);

  useEffect(() => {
    const el = ref.current;
    if (!el) return undefined;
    return observeElement(el, options, (entry) => {
      setInView(entry.isIntersecting);
    });
  }, []);

  return [ref, inView];
}

这个 Hook 的精妙之处在于借助刚才的共享 observer 工具类，让每个调用它的组件都不会额外创建 observer，在复杂列表里性能优势很明显。

4.3 动态列表和虚拟列表下的生命周期管理

动态列表场景里，比“观察”更重要的往往是“停止观察”。最常见的问题出现在点击筛选、搜索、切换 Tab 后，旧列表被移除但 observer 还引用着旧 DOM 节点，导致内存泄漏和后续回调的意外触发。

我处理列表场景的统一规范是：列表重新渲染之前，先对该列表容器内所有已观察元素逐一执行 unobserve，或直接调用暴露的清理函数；如果列表是分页追加而不是整体替换，就在需要时观察新元素，但不要对已卸载元素反复 observe。结合 WeakMap 记录状态，可以避免清理残留。

虚拟列表里元素会在滚动过程中被大量回收和重建，一个更实用的策略是：不在每次滚动时动态 observe 全部虚拟项，而是只观察虚拟列表中实际渲染出的那些 target 节点。虚拟容器内部的高度变化由外部滚动触发，IO 完全能感知到；一旦某个 target 进入视口，由业务回调决定是否触发曝光，曝光过的且列表不准备复用时 unobserve，这样能有效避免虚拟列表快速滚动时回调风暴。

4.4 回调里不要同步改布局，我会把它当铁律

IO 回调执行时，浏览器已经拿到了这帧的布局信息。如果回调里同步修改元素的高度、margin、display 等布局相关属性，会强制浏览器在下一帧之前做一次重排，如果新布局又改变了其它元素的交叉状态，浏览器就要多触发一轮 IO 回调，极端情况下会造成“观察-改布局-再观察-再改布局”的循环抖动。

我自己踩过一次比较隐蔽的坑：用 IO 实现列表懒加载时，滚动到接近底部后，回调里向列表尾部插入了新的 loading 占位 DOM，导致滚动容器高度变化，结果又触发了下一次回调，loading 被重复插入，列表疯狂跳动。解决方案是把对 DOM 的修改丢到 setTimeout(..., 0) 或 requestAnimationFrame 里，让回调先干净地结束，再由下一个渲染帧去更新页面。

这条规则值得写进团队代码规范：IO 回调里只做状态记录和“轻量数据准备”，所有的 DOM 修改、副作用都延后处理。

5. 常见问题与排查技巧实录

整合最近几个项目里收集到的高频问题，用速查表的形式记录下来，都是真实环境中反复出现的点：

大部分问题，归根结底是对“首次回调、阈值口径、根元素选择、生命周期清理”这四个细节理解不到位。排查时先看这四类，能省下不少时间。

5.1 兼容性降级：没有 IntersectionObserver 的环境怎么办

虽然现代浏览器里 IntersectionObserver 的支持度已经很高，但在一些 WebView 或旧版本系统里，这个 API 可能依然不可用。此时直接停止工作不可取，更稳妥的做法是运行时能力检测，并准备一个基于 getBoundingClientRect 的降级方案。

我的降级思路很朴素：如果环境不支持 IO，就退回到滚动监听方案，用 requestAnimationFrame 节流，每次滚动后手动计算目标是否与视口相交。降级方案只需要保证“核心功能可用”，比如懒加载、曝光，能够正确触发即可，性能不是首要考量，因为真正运行在旧环境的设备占比往往不高。

javascript复制const isIOSupported = typeof IntersectionObserver !== 'undefined';

if (!isIOSupported) {
  // fallback: 在 scroll/resize 时用 getBoundingClientRect 判断
}

不推荐引入一个大而全的 polyfill 硬凑，因为 IO 的兼容性问题主要出现在老 WebView，polyfill 在这种环境里的性能和一致性都不好，不如业务侧自己写一个几十行的降级判断来得直接。

5.2 与 ResizeObserver 配合，解决布局变化问题

IO 只负责“位置交叉”的监测，元素的尺寸变化并不在它的职责范围内。但布局里经常出现这样的情况：一个卡片因为内容加载完成后变高了，它原本在视口外的位置会被推到更下方；如果此时你只用了 IO，浏览器会在变换后重新计算交叉状态并触发回调，这没问题。

问题在于回调时机。元素尺寸变化时，IO 的回调通常会在下一帧触发，但如果你想在元素尺寸变化的瞬间就调整页面布局，仅靠 IO 是不够的。我常常在富文本内容区、评论列表这类异步加载内容里同时观察容器尺寸，容器高度变化后再重新确定某个锚点元素的位置是否真的掉出了屏幕。

做法是给容器挂一个 ResizeObserver，在回调里读取容器的最新高度，再做对应的滚动偏移校准。代码上要万分小心的是，ResizeObserver 回调里如果修改了容器自身高度，会形成循环，所以也必须通过一个“是否仍在变化中”的标记或 rAF 延后处理来切断循环。这两者组合用，能覆盖绝大多数“内容异步加载导致交叉状态变化”的场景。

最后的实际操作体会

做 IntersectionObserver 相关功能的这些项目里，我最大体会是：它的 API 很简单，但真正能发挥价值的地方，几乎都在 API 之外的细节上。回调触发时机要结合异步渲染模型来理解；曝光和打点要结合业务定义来判断；性能保障来自实例复用和清理，而不是盲目消灭所有监听。如果你正在做的功能涉及“元素是否出现在屏幕里”这类判断，我强烈建议先用 IO 想一遍：我的目标元素是谁，根容器是哪一层，可见到什么程度算是满足条件，状态变化后应该触发什么副作用。想清楚这四个问题，代码基本就写不坏。