前端埋点与监控系统架构设计

场景题：

“现有业务缺少数据观测能力，产品和数据团队希望了解新功能的 PV / UV、转化漏斗，研发团队还需要监控前端性能和线上异常。请设计一套前端埋点与监控系统。”

这道题不只是考察如何调用一个上报接口。完整答案应该覆盖：采集什么、如何采集、怎样可靠上报、服务端如何处理，以及如何保证数据质量、性能和隐私安全。

面试回答总框架

我会先统一 PV、UV、漏斗等指标口径，再用版本化事件模型规范数据。浏览器侧通过代码埋点、声明式埋点、性能 API、全局异常监听和框架错误边界采集数据；SDK 负责补充上下文、采样、限流、批量和有界缓存，常规阶段用 fetch，页面隐藏时用 sendBeacon 或 fetch keepalive 尽力冲刷。服务端负责校验、去重、清洗、存储、聚合和告警，关键交易数据与服务端事实对账，同时做好 Source Map、数据质量和隐私合规。

一、先明确目标和指标口径

监控数据通常分为四类：

类型	常见指标	主要用途
页面访问	PV、UV、访问时长、来源、退出页	流量分析
用户行为	点击、曝光、搜索、提交、支付结果	漏斗和产品分析
性能	TTFB、FCP、LCP、CLS、INP、接口及资源耗时	性能治理
稳定性	JS 异常、Promise 异常、资源加载失败、接口失败、白屏	告警和故障定位

设计前应与产品、数据和后端共同确定事件字典及统计口径。例如：

SPA 首次加载和路由切换是否都计算 PV；路由重定向是否计算；
UV 按匿名设备、登录用户还是两者合并去重；
“提交订单”统计点击、接口成功，还是服务端真正创建订单；
曝光需要露出多少面积、持续多久、一次会话是否去重。

其中 UV、转化率等聚合指标通常由服务端或数仓根据 user_id / anonymous_id、时间窗口和去重规则计算，前端只负责上报原始事件。支付成功等关键业务事实应以服务端事件为准，不能只信任容易丢失或伪造的前端埋点。

二、统一事件模型

不要让每个页面随意拼 JSON。SDK 应定义版本化的事件协议，并自动补充公共上下文：

interface TrackEvent {
  event_id: string;       // 每条事件唯一 ID，用于幂等去重
  event_name: string;     // 如 order_submit_success
  event_version: number;  // 事件模型版本
  event_time: number;     // 客户端发生时间
  event_type: 'page' | 'action' | 'performance' | 'error';
  properties: Record<string, unknown>;
  context: {
    session_id: string;
    anonymous_id: string;
    user_id?: string;
    page_url: string;      // 上报前应移除敏感查询参数
    referrer: string;
    release: string;       // 发布版本或 commit，用于关联 Source Map
    sdk_version: string;
    user_agent: string;
  };
}

事件名和属性应进入数据字典，注明负责人、触发时机、属性类型和是否包含敏感信息。TypeScript 类型或构建期 Schema 校验可以尽早发现错拼事件名、字段类型漂移等问题；服务端仍需做最终校验，因为客户端数据不可信。

anonymous_id 可用于登录前行为串联，登录后发送一次身份关联事件，而不是直接覆盖历史身份。session_id 则按约定的闲置时间或新访问规则更新。

三、数据采集

1. 行为埋点的三种方式

代码埋点

在明确的业务节点调用统一的 track 接口：

await submitOrder();
track('order_submit_success', { order_type: 'normal' });

它的语义最准，也能携带业务数据，适合支付成功、接口失败、状态变更等事件。缺点是有一定侵入性，因此业务只能依赖内部埋点接口，不应直接依赖某家第三方 SDK。

声明式埋点

DOM 点击等标准行为可以使用 data-*、React Hook 或 Vue 指令声明，再由统一采集层处理：

<button
  data-track-name="order_submit_click"
  data-track-position="footer"
  onClick={submitOrder}
>
  提交订单
</button>

document.addEventListener('click', (event) => {
  if (!(event.target instanceof Element)) return;

  const element = event.target.closest<HTMLElement>('[data-track-name]');
  if (!element) return;

  track(element.dataset.trackName!, {
    position: element.dataset.trackPosition,
  });
});

事件委托减少了监听器数量，也把埋点声明与发送实现解耦。要注意 Shadow DOM、事件未冒泡、元素重复点击，以及不要从 DOM 文本中自动收集密码、手机号等信息。

Vue 项目也可以封装 v-track 指令。指令负责绑定和清理 DOM 监听，公共参数补全、队列、采样和网络发送仍由统一 SDK 负责。业务结果埋点不应依附于 DOM 指令。

全埋点

SDK 自动记录页面、点击等交互，接入成本低，适合探索性分析；但数据量大、语义弱、容易采集敏感信息，DOM 改动也可能破坏元素定位。成熟系统通常以代码埋点和声明式埋点为主，全埋点为辅。

2. PV、停留和 SPA 路由

传统页面可以在初始化时记录 PV；SPA 还要监听路由成功切换，而不是只在 SDK 初始化时记录一次。框架项目优先接入路由器的 afterEach、location change 等正式钩子，避免仅改写 history.pushState 后漏掉 popstate、重定向或取消导航。

页面停留时间可在进入时记录 performance.now()，在路由切换、visibilitychange 或 pagehide 时结算。页面进入后台后是否继续计时必须先统一口径；大多数场景只累计可见时长。

曝光埋点适合使用 IntersectionObserver 判断元素可见比例，再配合计时器判断持续时间。达到曝光条件后是否取消观察，要根据“一次访问只计一次”还是“每次重新曝光都计算”的业务口径决定。

3. 性能采集

使用 Navigation Timing 和 Resource Timing 采集导航、资源、DNS、TCP、TTFB 等耗时；
使用 PerformanceObserver 采集 LCP、CLS、INP 等指标，优先使用经过兼容处理的 Web Vitals 库；
包装 fetch / XHR 可以记录接口耗时和状态，但要过滤上报接口自身，防止递归上报；
指标应带上页面、网络类型、设备、release 等维度，按 p75 / p95 等分位数分析，而不是只看平均值。

性能条目可能在页面生命周期后期才最终确定，应在页面隐藏时补发最终值。采集逻辑本身要控制主线程开销，并对高频数据采样。

4. 异常采集

// JS 运行时错误；capture=true 时也可捕获不冒泡的资源加载失败
window.addEventListener('error', (event) => {
  if (event instanceof ErrorEvent) {
    reportError(event.error ?? event.message, {
      filename: event.filename,
      lineno: event.lineno,
      colno: event.colno,
    });
  } else if (event.target instanceof HTMLElement) {
    reportResourceError(event.target);
  }
}, true);

window.addEventListener('unhandledrejection', (event) => {
  reportError(normalizeReason(event.reason));
});

还应接入框架错误边界：React 使用 Error Boundary，Vue 使用 app.config.errorHandler。React Error Boundary 不能捕获事件处理器、异步回调和自身内部错误，所以仍需要全局捕获和业务层 try/catch。

错误上报至少包含错误类型、message、stack、页面、用户操作轨迹摘要、release 和环境信息。相同错误应按指纹聚合并限流，避免故障发生后形成“上报风暴”。

生产构建生成 Source Map，但不要公开部署；监控服务根据 release + 文件名 + 行列号 在服务端还原堆栈。跨域脚本若希望获得完整错误信息，需要资源端允许 CORS，并正确设置 crossorigin，否则可能只得到信息有限的 Script error.。

四、可靠且低开销地上报

1. 常规发送、页面退出发送

页面存活期间优先使用 fetch 批量 POST。页面转入后台或即将被放入往返缓存时，在 visibilitychange（状态变为 hidden）及必要的 pagehide 中冲刷队列：

function flush(events: TrackEvent[]) {
  const body = JSON.stringify(events);
  const queued = navigator.sendBeacon(
    '/monitor/events',
    new Blob([body], { type: 'text/plain;charset=UTF-8' }),
  );

  if (!queued) {
    void fetch('/monitor/events', {
      method: 'POST',
      body,
      keepalive: true,
      headers: { 'Content-Type': 'text/plain;charset=UTF-8' },
    });
  }
}

document.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') flushQueue();
});

需要准确说明的是：

sendBeacon() 返回 true 只表示浏览器成功把数据加入发送队列，不代表服务端已经收到，也不保证一定送达；
sendBeacon 只能 POST，不能读取响应或自由设置请求头，复杂需求可使用 fetch(..., { keepalive: true })；
Beacon 和跨域图片都不会绕过 CORS、CSP、网络策略或服务端鉴权。跨域端点仍需正确配置 CORS；自定义请求头或非简单 Content-Type 还可能触发预检；
keepalive / Beacon 的待发送数据存在浏览器配额，不能把大批事件留到退出时一次发送。

beforeunload / unload 在移动端可能不触发，也会影响往返缓存，不应作为主要方案。

历史上的图片探针适合很小的 GET 数据，确实不需要读取跨域响应，但受 URL 长度、缓存、CSP、编码和只支持 GET 等限制。现代系统不应把 1×1 GIF 当作默认上报方式。

2. 批量、采样和重试

SDK 内维护有界队列，在以下时机发送：

达到条数或字节阈值；
定时器到期；
页面隐藏或路由切换；
严重异常等高优先级事件发生。

可用 requestIdleCallback 做低优先级整理，但必须提供定时器降级，不能依赖它一定执行。失败后使用有限次数的指数退避并加入随机抖动；网络离线时可短暂写入 IndexedDB，恢复后重传。队列必须限制大小和存活时间，避免占满存储。

每条事件携带 event_id，服务端以此幂等去重，因为重试可能造成重复。普通点击和性能事件可以按稳定规则采样，错误通常按错误指纹动态采样，支付等关键事件不采样。客户端时钟不可靠，服务端还应记录接收时间。

3. SDK 不能影响业务

初始化、序列化和发送都不能阻塞首屏；SDK 加载失败时业务照常运行；
SDK 内部全部容错，避免监控代码的异常再次污染业务；
限制队列、单条事件、批次字节数和操作轨迹长度；
上报域名应支持压缩、HTTP/2 或 HTTP/3，并监控 SDK 自身的丢弃率、发送成功率和耗时；
防止采集 fetch 上报请求本身，也防止 SDK 错误递归触发错误上报。

五、服务端链路与告警

一套完整链路通常是：

业务 / 浏览器探针
  → 统一采集 SDK
  → 内存队列与本地缓冲
  → 日志接入层（鉴权、限流、Schema 校验）
  → 消息队列
  → 清洗、去重、会话与用户关联
  → 明细存储 / OLAP / 数仓
  → 看板、漏斗、错误聚合和告警

接入层不能信任客户端字段，需要限制请求体、校验 Schema、防刷和脱敏。告警不应只看错误总数，而应结合错误率、受影响用户数、release、页面、地区及环比变化；新版本错误率突增时可联动灰度暂停或回滚。

关键业务漏斗可用前端行为说明“用户做了什么”，再与服务端订单、支付事实进行校验。这样既能分析用户在何处流失，也不会因前端丢包导致核心经营数字失真。

六、数据质量与隐私合规

埋点系统最容易被忽视的不是“发不出去”，而是“发出去的数据不能用”。需要建立：

事件字典、负责人、版本和变更评审；
开发环境调试面板、自动化测试、Schema 校验及线上数据巡检；
上报量、缺失率、重复率、非法字段率和端到端延迟监控；
敏感字段白名单与 URL 参数清洗，禁止采集密码、Token、身份证号、完整输入内容等；
按适用法律和产品策略获取用户同意，支持拒绝、删除、保存期限和最小化采集；
传输加密、权限控制、审计以及必要的字段加密或散列。

七、常见错误回答

错误回答	问题	更好的表达
“UV 由前端直接统计”	客户端只能产生身份和访问事件，跨端去重口径不可靠	前端上报原始访问，服务端按身份和时间窗口去重
“所有点击都自动上报即可”	数据量大、业务语义弱，还可能泄露输入内容	关键事件显式埋点，标准交互声明式埋点，全埋点只作辅助
“`sendBeacon` 保证送达”	它只保证尝试排队，断网、进程终止等仍会丢失	把它描述为退出阶段的尽力发送，关键事实由服务端记录
“图片上报没有跨域限制”	图片可跨域加载不等于绕过 CORS、CSP 和服务端策略	说明它不读取响应，但有 GET、URL 长度和 CSP 等限制
“监听 `window.onerror` 就够了”	会遗漏 Promise、框架、资源和业务捕获异常	组合全局监听、框架边界、业务捕获和服务端日志
“失败就一直重试”	会造成重复、存储膨胀和故障时的上报风暴	有界队列、有限退避、TTL，并用 `event_id` 幂等去重
“收集的信息越多越好”	增加性能、成本和隐私风险	按目标最小化采集，使用字段白名单、脱敏和保存期限

八、面试官递进追问

1. PV 和 UV 是前端算出来的吗？

不是。前端上报页面访问及身份标识，服务端按统一的用户身份、会话和时间窗口聚合。面试官借此检查你是否区分“原始事件”和“统计指标”，回答重点是统计口径在服务端统一。

2. 为什么还需要代码埋点，全埋点不够吗？

全埋点能知道某个元素被点击，却未必知道“订单创建成功”这种业务事实。关键业务节点需要显式语义和运行时属性。面试官在考察方案边界，重点是采集便利性不能替代业务准确性。

3. SPA 如何统计 PV 和停留时间？

在路由成功后记录新 PV，在路由离开、页面隐藏时结算可见停留时长，并处理重定向、取消导航和重复路由。面试官在考察浏览器生命周期，重点是一次文档生命周期不等于一次页面访问。

4. `error` 事件为什么使用捕获阶段？

资源加载错误不会像普通 DOM 事件一样冒泡，给 window 注册捕获监听可以统一发现它们；同时要用 ErrorEvent 和 event.target 区分运行时错误与资源错误。面试官在考察底层事件机制，重点是两类错误的结构和传播不同。

5. 为什么不在每次事件发生时立即请求？

高频小请求会增加连接、请求头和服务端处理开销。批量发送能降低成本，但批次过大会增加丢失范围和延迟，所以要结合条数、字节、时间及优先级触发。面试官在考察工程权衡，重点是实时性、可靠性和成本的平衡。

6. `sendBeacon` 和 `fetch keepalive` 如何选择？

只需 POST 且不关心响应时优先 Beacon；需要自定义方法、更多请求控制或读取响应时使用 fetch，退出阶段加 keepalive。两者都受浏览器配额和网络条件限制。面试官在识别 API 背诵，重点是能力差异而非“谁更高级”。

7. 重试为什么会造成数据不准，怎样解决？

客户端可能已经发送成功但没有得到可确认结果，重试后服务端会收到重复事件。每条事件生成稳定的 event_id，重试时保持不变，由服务端幂等去重。面试官在考察分布式系统意识，重点是至少一次发送与幂等消费配套。

8. 线上压缩错误怎样定位到源码？

上报 release、脚本 URL、行列号和 stack，服务端使用同 release 的 Source Map 还原；Source Map 应单独上传到监控系统而非公开发布。面试官在考察监控闭环，重点是错误必须和构建产物精确对应。

9. 如何验证埋点数据真的可靠？

在开发和测试阶段校验 Schema 与触发次数，线上监控缺失率、重复率、字段合法率和端到端延迟，关键指标再与服务端事实及数仓结果对账。面试官在考察实际项目经验，重点是监控系统自身也需要被监控。

10. 如何防止 SDK 拖垮业务？

异步加载、全面容错、有界缓存、按优先级采样限流，避免大对象序列化和递归采集，并监控 SDK 自身耗时与丢弃率。面试官在考察非功能设计，重点是可观测性不能成为新的故障源。

九、形成可迁移的理解

核心关键词是：统一口径、事件模型、分层采集、有界可靠性、数据治理。

一句话本质：埋点系统把浏览器里的行为和故障转换为可治理的事件流，在不影响业务的前提下送入数据系统，并最终形成可信的指标和定位证据。

业务事实 / 浏览器信号
  → 规范化事件
  → 队列、采样、批量、发送
  → 服务端校验与幂等处理
  → 指标、漏斗、告警与决策

这套思路也可以迁移到后端日志、移动端埋点、审计日志和消息队列设计：都需要明确数据契约、传输语义、幂等、限流、可观测性与合规边界。

十、不同时间长度怎么回答

1 分钟：使用开头的“面试回答总框架”，覆盖口径、采集、发送、服务端和治理五层。
3 分钟：补充行为、性能、异常的采集方式，解释批量队列、Beacon 的真实语义、服务端去重和 Source Map。
10 分钟：沿本文完整链路展开，再讨论 SPA 生命周期、采样重试、关键数据对账、告警策略、数据质量与隐私，并主动接受边界追问。

十一、面试总结

可以用下面这段话收尾：

我会先和产品、数据统一事件及指标口径，再设计版本化事件模型。行为采集采用代码埋点与声明式埋点结合，SPA 路由、Web Vitals、全局异常和框架错误边界分别覆盖访问、性能与稳定性。SDK 统一补充上下文，通过有界队列批量上报，在页面隐藏时用 sendBeacon 或 fetch keepalive 尽力冲刷，并用采样、限流、重试和事件 ID 去重控制成本与可靠性。服务端完成校验、清洗、聚合、存储和告警，关键业务事实与服务端日志对账；最后用数据治理、Source Map 和隐私合规保证系统长期可用。

#前端埋点与监控系统架构设计

#面试回答总框架

#一、先明确目标和指标口径

#二、统一事件模型

#三、数据采集

#1. 行为埋点的三种方式

#代码埋点

#声明式埋点

#全埋点

#2. PV、停留和 SPA 路由

#3. 性能采集

#4. 异常采集

#四、可靠且低开销地上报

#1. 常规发送、页面退出发送

#2. 批量、采样和重试

#3. SDK 不能影响业务

#五、服务端链路与告警

#六、数据质量与隐私合规

#七、常见错误回答

#八、面试官递进追问

#1. PV 和 UV 是前端算出来的吗？

#2. 为什么还需要代码埋点，全埋点不够吗？

#3. SPA 如何统计 PV 和停留时间？

#4. error 事件为什么使用捕获阶段？

#5. 为什么不在每次事件发生时立即请求？

#6. sendBeacon 和 fetch keepalive 如何选择？

#7. 重试为什么会造成数据不准，怎样解决？

#8. 线上压缩错误怎样定位到源码？

#9. 如何验证埋点数据真的可靠？

#10. 如何防止 SDK 拖垮业务？

#九、形成可迁移的理解

#十、不同时间长度怎么回答

#十一、面试总结