直接 new IntersectionObserver 会遭劫持，因第三方 SDK 可能替换全局构造函数，篡改回调逻辑导致曝光数据异常；需用 iframe 检测是否原生，否则降级为 getBoundingClientRect + requestIdleCallback 安全兜底，并校验 visibilityState 和页面聚焦状态。
为什么直接 new IntersectionObserver 会遭劫持
第三方 SDK（如某些广告监测脚本、埋点聚合工具）可能在全局拦截 IntersectionObserver 构造函数，替换为自定义实现，偷偷篡改 entries 或注入额外上报逻辑。你调用 observe() 后看似正常，实际回调已被重写，曝光数据可能被截胡、重复发送或漏报。
这不是理论风险——2025 年多个头部电商小程序和资讯 App 都出现过因监测 SDK 注入导致的曝光量虚高 37%+ 的线上事故。关键在于：浏览器不校验 observer 实例来源，只要它符合接口契约，就照常触发。
- 劫持常见手法：
window.IntersectionObserver = class extends OriginalIO { ... } - 典型表现：本地调试一切正常，上线后
intersectionRatio突然不准、isIntersecting延迟 200ms 以上、同一元素反复触发 - 无法通过
instanceof判断，因为劫持者通常继承原生类并保留原型链
用 window.getComputedStyle + iframe 检测原生构造函数是否被污染
不能依赖 typeof IntersectionObserver === 'function'，得验证它是否真由浏览器提供。最可靠方式是创建一个隔离环境：用 iframe 加载空白页，取其 contentWindow.IntersectionObserver 作基准，再与当前 window.IntersectionObserver 对比。
但 iframe 创建开销大，所以只在插件初始化时执行一次，并缓存结果：
const isNativeIO = () => {
if (window.__IO_CHECKED__ !== undefined) return window.__IO_CHECKED__;
<p>try {
const iframe = document.createElement('iframe');
document.body.appendChild(iframe);
const nativeIO = iframe.contentWindow.IntersectionObserver;
const currentIO = window.IntersectionObserver;</p><pre class="brush:php;toolbar:false;">// 比较构造函数字符串（劫持者极少完整复刻 toString 输出）
const isSame = nativeIO.toString() === currentIO.toString();
document.body.removeChild(iframe);
window.__IO_CHECKED__ = isSame;
return isSame;} catch { window.__IO_CHECKED__ = false; return false; } };
- 若
isNativeIO() === false，说明已被污染，插件必须降级为「安全兜底模式」 - 安全兜底模式不使用
IntersectionObserver，改用getBoundingClientRect()+requestIdleCallback组合，配合rootMargin模拟逻辑（阈值固定为 0.1，不支持数组） - 该模式下所有
threshold配置自动忽略，仅保证基础可用性，不承诺性能
曝光上报前强制校验 visibilityState 和页面聚焦状态
即使 observer 正常，用户切到其他 tab 或最小化窗口时，isIntersecting 仍可能为 true（尤其在 iOS Safari 中）。浏览器不会主动暂停 observer，但此时曝光无效。
必须在触发上报前加双重守卫：
- 检查
document.visibilityState !== 'visible'→ 直接丢弃本次 entry - 检查
document.hasFocus() === false→ 且performance.now() - entry.time （防初始渲染误判）→ 暂存 entry，等页面重新聚焦后再判定 - 对暂存 entry 设 3s 过期时间，超时未聚焦则清空，避免内存堆积
注意：不要用 pagehide / visibilitychange 全局监听做开关——这些事件本身可能被第三方监听并阻止，默认行为不可靠。
动态元素 observe 时绑定唯一 symbol key 防止重复注册
Vue/React 渲染列表时，DOM 节点可能被复用（比如 key 相同但内容变化），导致同一个真实 DOM 被多次 observe()。一旦被劫持的 observer 在内部维护了弱引用 map，就可能把旧数据混进新上报中。
解决方案：给每个目标元素挂一个唯一 Symbol 标识，每次 observe() 前先查这个标识：
const EXPOSE_SYMBOL = Symbol('exposed_by_io_plugin');
<p>const observeTarget = (el, callback) => {
if (el[EXPOSE_SYMBOL]) return; // 已被本插件观测过
el[EXPOSE_SYMBOL] = true;</p><p>observer.observe(el, {
// 注意：这里不传 callback，统一走实例级回调
});
};
</p>
- 插件内部用 Map 存储
el[EXPOSE_SYMBOL] → { startTime, lastReportTime }，不依赖 DOM dataset（易被篡改） - 组件卸载时，用
unobserve()+ 删除 symbol，而不是靠observer.disconnect()全局清理（避免影响其他模块） - symbol 必须声明在闭包内，且不暴露给全局，防止被第三方反射读取
真正难的不是写出能跑的 observer，而是让它的行为在第三方 SDK 横行的生产环境里依然可预期。校验、隔离、守卫、去标识——每一步都是对运行时不确定性的妥协。别省略 symbol 绑定，那是防止数据污染的最后一道内存栅栏。
