IntersectionObserver threshold 数组的触发粒度

IntersectionObserver 的 threshold 数组控制的是“可见比例跨过哪些刻度时通知回调”，不是滚动过程中的逐像素监听。比如设置 [0, 0.5, 1]，目标从不可见进入、超过 50% 可见、达到完全可见，以及反向离开这些比例线时才会产生通知。数组越密，比例变化被切成的档位越细；但它仍然是阈值越界通知，不等于每次滚动都调用一次函数。

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

threshold 数组到底控制什么

把 threshold 想成一组“门槛”更准确。浏览器计算目标和 root 的相交比例，只有比例从门槛的一侧越到另一侧，才会把变化排进观察器回调。数组 [0, 0.25, 0.5, 0.75, 1] 适合把曝光过程分成五个可解释的档位；单个 0.5 则只关心是否越过一半。

阈值数组即使乱序，实例上的 observer.thresholds 也会以递增顺序呈现。构造器选项没有 thresholds 这个复数配置项；误写后通常会回到默认的 [0]，这是排查“为什么只触发一次”时最先要看的地方。

用最小示例验证触发粒度

const target = document.querySelector('.card');

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    // 用比例判断当前档位，避免把一次回调误当成一次滚动事件。
    const ratio = entry.intersectionRatio;
    if (entry.isIntersecting && ratio >= 0.5) {
      entry.target.classList.add('half-visible');
    } else if (ratio 

这里的 root: null 表示使用顶层视口，rootMargin 不改变观察范围。若目标一次布局变化直接从 0.1 跳到 0.9，浏览器可能在一次回调中报告多个越过的阈值；因此不能假设 entries.length 永远等于 1，也不要只读取 entries[0] 就代表所有目标。

回调里如何判断方向和边界

intersectionRatio 告诉你当前相交比例，isIntersecting 更适合判断是否已经进入相交状态。两者不是同一个概念：目标可能与 root 共享边界但没有可见像素，也可能因为尺寸、裁剪或布局变化出现比例为 0 的边界情况。需要排序多个通知时，使用 entry.time，不要依赖回调数组的偶然顺序。

密集阈值的边界与降级处理

把数组拆成 100 个甚至更多档位，只是提高通知的离散粒度，并不会把 IntersectionObserver 变成像素级进度条。移动端滚动、复杂裁剪和多个目标同时变化时，回调仍可能批量到达。若确实需要连续动画，先评估 requestAnimationFrame 或其他适合动画的机制；IntersectionObserver 更适合“跨过某个比例后做一次动作”。

另外，阈值依赖目标的边界框和 root 的裁剪结果。修改 rootMargin、容器的 overflow 或目标尺寸，都会改变你看到的比例。兼容性要求较高时，可保留传统的初始可见状态或轻量滚动监听作为降级，但不要让两套逻辑同时重复执行同一个副作用。

相关问题

threshold 和 thresholds 为什么一个单数一个复数？

前者是构造器选项名，接收数字或数组；后者是实例上的只读属性，返回排序后的阈值列表。

阈值数组越长，回调就越接近逐像素吗？

不会。它只增加比例门槛，回调仍按浏览器观察周期批量派发，不能当作精确像素事件流。

为什么 observe 后马上收到一次回调？

观察器需要把目标当前相交状态同步给回调，这是初始化通知；后续再根据阈值越界处理变化。