IntersectionObserver是当前最稳妥、性能最好的曝光统计方案，但需显式指定root容器、合理设置rootMargin和threshold数组、按需注册监听、及时销毁实例，并结合时间阈值判断有效曝光。
直接说结论：不用自己写 scroll + getBoundingClientRect，用 IntersectionObserver 是当前最稳妥、性能最好、浏览器原生支持的曝光统计方案；但照着 MDN 示例直接贴进项目，90% 会漏埋、误报或内存泄漏。
为什么 IntersectionObserver 的回调总不触发？
常见错误是没指定 root 或 rootMargin，导致观察器默认以整个视口（viewport）为参照，而你的目标元素在 scroll-view、div.overflow-auto 这类局部滚动容器里——它根本“看不见”你想要的区域。
- 必须显式传入滚动容器 DOM 节点给
root参数，例如：new IntersectionObserver(cb, { root: document.querySelector('.list-container') }) -
rootMargin不是可选的“锦上添花”，而是解决“刚露头就上报”的关键：设成"0px 0px 100px 0px"表示向下多观察 100px，避免用户一滑就触发、一停就取消 - uni-app 中不能直接用
document.querySelector，得用uni.createIntersectionObserver(instance)并配合.relativeTo('.selector')指定容器
threshold 设成 0.5 还是 [0, 0.5, 1]？
设单值 0.5 只会在相交比例**恰好等于 0.5** 时触发一次；而业务要的是“≥ 0.5 且停留 ≥ 300ms”，所以必须靠 JS 自己记状态——threshold: [0, 0.5] 才是合理起点，它能让你拿到 intersectionRatio 从 0 → 0.5 → 1 的完整变化过程。
- 不要依赖
isIntersecting判断“是否可见”，它只反映是否 > threshold，无法区分是刚进还是已稳定 - 每次回调都要检查
entry.intersectionRatio >= 0.5，再结合Date.now()计算持续时间，否则会把“闪现”当成有效曝光 - 移动端 WebView 中部分安卓机型对
threshold数组支持不全，降级策略是 fallback 到[0, 0.25, 0.5, 0.75, 1]多采样
动态渲染的列表项怎么监听？
Vue/React 渲染完才挂 DOM，但 observe() 必须传真实 DOM 节点——直接在 mounted 里查 querySelectorAll('.item') 会拿不到新节点，尤其分页加载或搜索刷新后。
立即学习“前端免费学习笔记（深入）”；
- 不要在初始化时一次性 observe 所有元素，改用「按需注册」：每个列表项组件内部自己创建 observer 并 observe 自身根节点
- uni-app 中注意
onUnload必须调observer.disconnect()，否则页面跳走 observer 还在后台跑，造成内存泄漏和重复上报 - React 函数组件用
useEffect+ cleanup 返回observer.disconnect；Vue3onBeforeUnmount同理 - 避免在循环中反复 new IntersectionObserver，复用一个实例 + 多次
observe()更轻量
真正难的不是监听是否出现，而是定义“什么才算一次有效曝光”：滚动过快、元素尺寸突变、iframe 嵌套、WebView 缓存导致的 boundingClientRect 错位……这些边界情况不会报错，但会让数据失真。上线前务必用真机慢速滚动+断点验证 intersectionRatio 变化节奏。
