IntersectionObserver：页面曝光统计的现代解决方案
说到页面元素的曝光统计，技术选型其实很明确：直接使用 IntersectionObserver。至于手动监听滚动事件、计算元素位置（getBoundingClientRect）那套传统方案，可以果断放弃了。原因很简单：性能开销大、容易漏报，而且各种浏览器兼容性问题处理起来相当棘手。
为什么 IntersectionObserver 是当前唯一合理选择
传统方案的核心问题在于性能。手动监听滚动并频繁调用 getBoundingClientRect 会强制触发浏览器回流（reflow），在长列表或复杂动画场景下，帧率掉到30fps以下是常有的事。而 IntersectionObserver 是浏览器原生提供的异步API，其回调执行不会阻塞主线程，并且能精准地感知元素进入或离开视口的时机。
它的优势远不止于此：
- 触发方式多样：它不依赖于滚动事件。即使用户使用键盘方向键导航、触控板惯性滑动，或者通过代码调用
scrollIntoView，它都能可靠地捕获到。 - 精细的可见度控制：通过配置
threshold阈值（例如设为[0, 0.1, 0.5, 1]），可以轻松区分元素“刚露头”、“一半可见”、“完全可见”等不同状态，满足更细致的业务需求。 - 强大的布局兼容性：对于
position: fixed、CSStransform变换、甚至是iframe内嵌的内容等复杂布局场景，它都能稳定工作。手写方案在这些场景下基本难以招架。 - 兼容性已无忧：目前主流浏览器支持度已相当完善：Chrome 51+、Firefox 55+、Safari 12.1+、Edge 79+均支持。移动端方面，iOS Safari 12.2+ 也已支持。尤其值得注意的是，国内常见的微信WebView（X5内核）从2021年起就已全量支持，可以放心使用。
曝光上报必须加 500ms 阈值，否则数据严重失真
这里有一个关键细节容易被忽略：如果用户快速滚动页面，一个元素可能在视口内只是“一闪而过”，停留时间仅有几十毫秒。这种“闪现”显然不应该被计为一次有效曝光。因此，所有用于生产环境的曝光逻辑，都必须引入最小可见时长的判断。IntersectionObserver 本身并不提供时间维度的信息，这就需要我们自行记录时间戳。
具体可以这样实现：
- 当
entry.isIntersecting === true（元素开始进入视口）时，记录当前时间戳（Date.now()），并将其存储在该元素的dataset或一个全局的Map中，例如：el.dataset.observeStart = Date.now().toString()。 - 当
entry.isIntersecting === false（元素离开视口），或者后续回调中entry.intersectionRatio > 0时，计算当前时间与存储的开始时间的差值。 - 只有当时长满足预设条件（例如
Date.now() - Number(el.dataset.observeStart) >= 500）时，才触发真正的曝光上报逻辑，并清空存储的时间戳，避免重复上报。 - 特别注意：不能仅仅依赖
isIntersecting的布尔值变化。由于浏览器的优化机制（如防抖）、observer自身的节流或暂停，这个状态变化可能会有延迟。因此，结合时间戳判断是保证准确性的必要步骤。
动态插入的元素要重新 observe，但别每次都 new Observer
在单页面应用（SPA）中，通过Vue/React动态渲染的列表、分页加载的内容或懒加载的图片，在插入DOM后，并不会自动被已有的 IntersectionObserver 实例观测到。然而，如果为每个新元素都创建一个新的Observer实例，将会导致严重的内存泄漏和性能浪费。
正确的做法是：
- 实例复用：在全局或模块级别，只初始化一个
IntersectionObserver实例。之后对于所有需要观测的新元素，都调用这个单一实例的observer.observe(el)方法。 - 确保DOM已挂载：必须在元素被实际添加到DOM树之后再进行观测。在React中，可以在
useEffect钩子中执行；在Vue中，则可以利用nextTick或组件的mounted生命周期钩子。 - 及时清理：在元素被销毁（从DOM中移除）之前，务必调用
observer.unobserve(el)。否则，Observer会持续持有对该DOM元素的引用，导致其无法被垃圾回收（GC），这是常见的内存泄漏点。 - 指令中的注意事项：如果使用自定义指令来封装曝光逻辑（例如Vue的
v-expose），务必在指令的unmounted（或类似）钩子中执行unobserve操作。这一点非常容易被忽略，需要格外留意。
上报队列要用 localStorage，别只靠 sessionStorage
考虑这样一个场景：用户滑动到了页面底部，触发了曝光事件，但上报请求还没来得及发出，用户就关闭了浏览器标签页。或者，当时网络突然中断。如果待上报的数据只存储在 sessionStorage 中，那么这些数据将永久丢失。一个可靠的埋点系统，必须保证数据“至少送达一次”。
存储策略应该这样设计：
- sessionStorage 用于临时状态：可以用来暂存那些“正在被观测中”的元素ID或队列（例如
to-observe）。页面关闭即清理，这是合理的。 - localStorage 用于持久化数据：所有确认需要上报的数据（
to-report队列），必须写入localStorage。在页面每次加载时，都需要检查localStorage中是否有之前残留的未上报数据，如果有，应立即尝试重新上报。 - 完善的失败处理：上报成功后，从
localStorage中移除对应的条目；如果上报失败，则保留数据，等待下一次页面初始化时重试（建议设置重试次数上限，例如最多3次，避免无限堆积）。 - 考虑存储异常：
localStorage.setItem操作可能会因用户禁用本地存储或存储空间已满而抛出错误。因此，需要用try...catch进行包裹，失败时降级到内存队列中，并给出适当的警告提示。
最后，还有一个容易被绕过的细节：IntersectionObserver 的回调函数中接收到的 entries 数组，其遍历顺序可能与DOM元素的实际插入顺序不一致。这会导致同一屏内多个模块的曝光上报时序发生错乱。如果业务上要求严格的保序（例如，首屏的模块A必须在模块B之前曝光），那么需要在开始观测（observe）之前，就按照DOM顺序预先存储好索引或顺序标识，而不能仅仅依赖回调中 entries 的顺序。
