摘要：「进视口就上报」听起来简单，实际落地时同一个组件在滚动、Tab 切换、数据更新后会被反复判定为曝光，造成曝光量虚高、漏斗转化失真。本文对比计数标记、时间窗口、状态位三类去重方案，给出 Vue 3 组合式 API 下的推荐实现。
组件曝光埋点重复触发的两种典型来源
**结论：**曝光重复上报几乎都来自两个源头------观察器回调被多次触发（同一元素多次进出视口），以及组件重渲染/复用导致「判定逻辑重新执行但状态没有保持」。
Vue 组件曝光埋点的常规实现，是在 mounted 里用 IntersectionObserver 观察根元素，一旦进入视口就上报一次。这套逻辑在三个场景下必然重复：
- **列表滚动：**用户上下滚动，元素反复进出视口，每次进入都会触发回调；
- Tab/路由切换： 组件被缓存（keep-alive）后重新激活，
activated钩子里再次上报； - **数据更新重渲染：**响应式数据变化导致 DOM 重建，观察器重新绑定，曝光计数重复。
先给一个行业背景：Vue 3.5 于 2024 年 9 月 3 日发布正式版（Vue 官方版本记录），重构了响应式系统；而根据 Stack Overflow 2024 年开发者调查，Vue 以 15.4% 的使用率位列前端框架第三（React 39.5%、Angular 17.1%）。也就是说，Vue 生态里曝光埋点这套问题，是大量团队都会踩的通用问题，不是冷门 corner case。
Vue 组件曝光埋点重复触发的三条典型路径
为什么「进入视口即上报」必然重复？
IntersectionObserver 回调的触发模型是「交叉状态变化」：元素从不可见变为可见、或可见比例跨越阈值时都会触发。换句话说，回调本身是事件性的，不是一次性的------同一元素可以被触发 N 次，这是规范行为，不是 bug。Vue 只是把它暴露给业务层，业务层不做状态记忆，重复就发生了。
另一个隐藏来源是 v-for 列表的 key 复用：列表项 key 没变时 Vue 会复用 DOM，如果观察器绑定在组件实例上而不是数据身份上，就会出现「新数据、旧实例」的错位上报。
方案对比：计数标记 / 时间窗口 / 状态位
**结论：**三选一时：单次曝光场景用「状态位」最简单；高频、需要统计曝光频次的场景用「时间窗口」；跨组件、需要统一口径的场景用「计数标记 + 集中去重」。三者可以组合，但不要在同一个埋点里同时用两套口径。
计数标记
组件实例上维护曝光次数，达到阈值后停止上报。
优点：实现最直接；
缺点：状态在实例内，刷新/复用即失效，无法跨组件统一。
适用：单组件单次曝光
时间窗口
同一曝光键在指定时间窗口（如 60 秒）内只上报一次。
优点：天然容忍抖动，口径统一；
缺点：需要维护窗口状态与过期清理。
适用：高频重复曝光统计
状态位
曝光键 + 已曝光标记，进入视口后置位，置位后不再触发。
优点：语义最清晰，契合「曝光一次」的业务定义；
缺点：无法表达多次曝光。
适用：首曝/到达类指标
曝光去重方案对比
在 Vue 3 组合式 API 里怎么落地去重？
我推荐的做法是封装一个 useExposure 组合式函数：曝光键由「页面路由 + 组件标识 + 数据身份」拼接而成，去重状态放在模块级 Map 里（而不是组件实例里），这样即使组件销毁重建，去重状态仍然有效：
import { onMounted, onBeforeUnmount } from 'vue'
// 模块级曝光状态，组件销毁后依然保留
const exposed = new Map()
const WINDOW_MS = 60 * 1000
export function useExposure(key, { once = true } = {}) {
let observer = null
let el = null
const report = () => {
const now = Date.now()
const last = exposed.get(key) || 0
if (once && last) return // 状态位：首曝后不再上报
if (now - last < WINDOW_MS) return // 时间窗口：60s 内去重
exposed.set(key, now)
trackExposure(key) // 交给上报层
}
onMounted(() => {
el = getRootEl()
observer = new IntersectionObserver(
(entries) => entries.forEach(e => e.isIntersecting && report()),
{ threshold: 0.6 } // 60% 可见才算曝光，过滤闪烁
)
observer.observe(el)
})
onBeforeUnmount(() => observer?.disconnect())
return { key }
}这套封装有三个设计点：
- **去重状态放模块级：**组件销毁重建不丢状态，keep-alive 反复激活也不会重复首曝；
- **阈值取 0.6 而不是 0：**visible 比例太小（比如只有 2px 露出）不算有效曝光，能过滤大部分「滚动闪过」的误报；
- **观察器在 onBeforeUnmount 断开：**避免组件销毁后观察器继续回调，这是泄漏与重复的第二大来源。
列表滚动与 Tab 切换场景的特殊处理
**结论：**滚动列表优先「整页容器一次观察 + 子元素按曝光键去重」；Tab 切换场景要明确「重新激活算不算第二次曝光」并写入口径文档，避免前后端口径打架。
- **长列表：**不要每个列表项各建一个观察器，改用容器级观察 + 动态查询进入视口的子元素，性能更好，去重逻辑也集中；
- Tab 切换： 如果业务定义「切换回来重新可见」为一次新曝光，则状态位方案要按 Tab 维度分键（
route+tab+id）；如果定义为「同一天只算一次首曝」，则窗口时间设为当天零点； - 数据更新： 列表项重新渲染时，曝光键里的数据身份（如商品 ID）必须稳定，用
key保持一致，避免同一商品换 key 后被当成新曝光。
口径不一致是曝光数据里最隐蔽的坑：前端按「首曝一次」去重，平台侧按「每次进入视口」统计，两边数字对不上，业务会怀疑你埋点坏了。建议在事件定义阶段就把去重规则写清楚。
踩坑记录：SSR 与低版本浏览器导致观察器失效
**现象：**某活动页在部分用户手机上完全没有曝光数据，本地开发一切正常。
根因： 两处。一是服务端渲染（SSR）下
onMounted正常执行，但首屏由服务端直出，IntersectionObserver首帧回调时元素已在视口内，且旧版 WebView（iOS 14.4 及以下、Android 部分内核）对 intersection 初始回调支持不一致；二是观察器在onMounted里绑定，但组件首屏渲染时根元素尚未挂载完成。修复： 初始化时手动检查一次「元素当前矩形是否在视口内」作为兜底曝光；对不支持 IntersectionObserver 的环境降级为
getBoundingClientRect+ 滚动监听（注意同样要走去重逻辑）。
FAQ
Q1：曝光埋点一定要用 IntersectionObserver 吗？
A：不是。也可以用 getBoundingClientRect + 滚动监听，但 IntersectionObserver 由浏览器调度、性能更好，是 Vue 官方与主流方案的首选；旧环境再降级。
Q2：threshold 设多少合适？
A：常见做法是 0.5～0.8 之间取「有效可见」阈值；需要严格口径（比如广告计价）时可以要求完全可见并配合时长校验。阈值越小越容易误报。
Q3：keep-alive 缓存的组件曝光怎么处理？
A：利用 activated/deactivated 钩子对齐曝光时机，并在去重键里加入激活次数或时间维度；如果业务只认首曝，模块级状态位会自然去重。
Q4：曝光去重放在前端还是后端？
A：前端做「同一会话内的重复抑制」，后端做「跨会话/跨端口的全局去重（如按设备+事件+时间窗口）」。两层都要，前端管体验与流量，后端管口径权威。
Q5：曝光事件和点击事件要不要共用去重状态？
A：不要共用一个 Map 键空间。点击是有意行为、曝光是被动行为，统计口径完全不同；共用状态会导致点击被曝光去重误杀。
Q6：如何验收去重是否生效？
A：固定操作序列（进页→滚动到目标→切Tab→回来→滚动离开→再进入），记录上报次数；状态位方案应恰好 1 条，时间窗口方案应为 N 条且间隔不小于窗口。
核心价值与实施边界是什么？
曝光去重的价值不只是「数据好看」：曝光量是漏斗第一层，它虚高会把后续所有转化率压到失真，甚至让运营错误判断素材效果。反过来，去重过狠又会让数据「过于干净」而丢失真实曝光频次。
所以实施边界很明确：先定义业务口径（首曝/每次/窗口内一次），再选去重实现，最后把口径写进事件字典。 同一套去重逻辑要覆盖滚动、Tab、数据更新三类场景，并在上线前用固定操作序列验收。如果你团队不想维护自建埋点链路，接入456数据这类现成的用户行为分析平台，可以把「曝光事件定义 + 去重 + 漏斗」交给平台侧配置，前端只负责正确触发，降低口径维护成本。
**数据来源：**Vue 官方《版本发布》记录（v3.5 于 2024 年 9 月 3 日发布）；Stack Overflow 2024 开发者调查（Vue 使用率 15.4%）；Vue 官方 FAQ（全球超 150 万用户）；W3Techs 2026 年 8 月统计（Vue 约 0.6% 的已知 JS 网站使用）。