前端监控 SDK 公共素材

使用说明

• 前端监控 SDK 怎么讲 和 Web 性能监控准确性怎么讲 统一从本页引用公共口径。
• 如果要改监控 SDK 的短讲法或准确性答法，优先改本页。

一句话定性

如果让我讲前端监控 SDK，我不会讲成“采几个指标然后上报”，我会讲成“做一套不打扰业务、还能持续扩展的前端观测基础设施”。

30 秒版本

前端监控 SDK 这类项目，我一般会从架构分层开始讲。核心层负责统一初始化、插件机制、标准事件模型和上报接口；浏览器适配层负责错误采集、性能采集和 transport；再往下是浏览器工具层，比如 Web Vitals、环境信息和一些通用能力。这样做的目标不是单纯把数据发出去，而是让 SDK 能跨框架复用、按插件扩展，并且在真实业务里尽量轻、尽量稳。

1 分钟版本

如果让我设计一个前端监控 SDK，我最先考虑的不是怎么监听 window.onerror，而是整个 SDK 的边界和演进方式。因为监控需求一定会越来越多，今天可能只有错误和性能，后面很可能会加行为采集、接口耗时、路由切换、白屏检测。如果一开始只是写几个监听器，后面很快就会失控。

所以我一般会先把它拆成三层。第一层是 core，只放初始化流程、插件机制、标准事件模型和 transport 抽象；第二层是浏览器适配层，负责浏览器环境下的错误和性能接入；第三层是工具层，提供 Web Vitals、环境信息、时间工具这些通用能力。这样核心层不依赖具体框架，React、Vue、Vanilla 都只是接入方式不同。

在能力上我通常会拆成四块：异常监控、性能监控、上报链路和公共上下文。异常监控负责 JS 错误、Promise 未捕获、资源错误；性能监控负责 Web Vitals 和 Performance API；上报链路负责批量、重试、限流、离线缓存；公共上下文负责页面路径、浏览器信息、应用版本和用户标识这些补充字段。

我觉得这个题真正能拉开差距的地方，是你有没有把它当成一套可演进的基础设施来设计，而不是一个只能跑通 demo 的脚本。

2 到 3 分钟版本

监控 SDK 这个题，我通常不会从 API 细节开始讲，而是先讲设计目标。因为这类 SDK 在业务里承担的是底层观测能力，它既要尽量全面，又不能影响页面本身，所以“轻、稳、可扩展”会比“先把功能堆上去”更重要。

我一般会先做架构分层。核心层只负责跟运行环境无关的东西，比如统一初始化、插件机制、标准化数据模型和上报接口。这一层不直接依赖 window、document，这样它天然更容易做到跨框架、跨环境复用。浏览器适配层再去处理浏览器特有能力，比如 window.onerror、unhandledrejection、Performance API、sendBeacon。再往下是一些浏览器工具层，像 Web Vitals、环境信息和工具函数。

从功能上看，我一般会拆成四块。第一块是异常监控，负责运行时错误、Promise 异常、资源加载错误，后面也可以扩展接口异常。第二块是性能监控，核心是 Web Vitals 和 Navigation Timing，不会只看一个 load 时间。第三块是数据上报模块，负责批量上报、失败重试、限流、离线缓存。第四块是公共上下文模块，负责把路径、浏览器信息、版本号、用户标识这些东西补到每条事件里。

这里我觉得最关键的设计点其实是插件化。因为监控 SDK 的能力一定是越来越多的，如果没有插件机制，新增一个监控能力就要去改核心流程，后面维护成本会越来越高。所以我会把错误监控、性能监控、行为采集都设计成 integration 或 plugin，SDK 初始化时统一注册。这样新增能力时，只要加插件，不需要改核心。

另外一个很重要的点是上报链路的稳定性。监控 SDK 不能为了多采一点数据，把业务页面拖慢。所以正常上报我会用 fetch，页面退出时优先考虑 sendBeacon，同时做批量、采样、限流、去重。弱网或者离线场景下，再考虑本地缓存和有限重试。

如果让我最后总结，我会说这类题真正想考的不是你会不会采错误，而是你能不能把它设计成一套可持续演进、又不伤害业务体验的前端基础设施。

性能监控怎么讲

性能监控我不会只看一个 load 时间，而是优先看 Web Vitals，比如 FCP、LCP、CLS、TTFB，必要时补 INP。采集上优先用 PerformanceObserver 和 PerformanceEntry，同时注意 buffered: true，避免 SDK 初始化太晚漏掉早期指标。真正有价值的不只是采到一个数字，而是尽量给出归因信息，让数据后面能定位问题。

跨框架怎么做

我会把跨框架理解成“核心稳定，适配层变化”。也就是说核心层不直接写 React 或 Vue 逻辑，而是定义统一的数据模型和插件接口；React 单独接 ErrorBoundary，Vue 单独接 app.config.errorHandler，Vanilla 直接监听全局错误。这样新增一个框架，只是新增适配层，而不是改核心。

最难的地方

我觉得最难的是平衡。你既要尽量采得全，又不能让 SDK 自己变成性能负担；既要保证数据链路稳定，又不能因为重试和补偿把业务拖慢；还要让它后续能继续扩。所以这题真正难的是基础设施设计，不是监听 API 本身。

监控准确性一句话

性能监控难的不是把指标采出来，而是保证采出来的数据真的可信。

监控准确性 30 秒

如果面试官问性能监控准确性，我不会只说 PerformanceObserver，我会重点讲数据校准。比如 SDK 初始化晚了要用 buffered: true，CLS 不能简单累加，要过滤 hadRecentInput 并按 session window 计算，LCP 和 FCP 还要处理后台页、prerender、bfcache 这些场景。不然数据看起来很多，实际上没法用。

监控准确性 1 分钟

我理解性能监控的难点不在采集 API，而在数据可信度。因为 PerformanceObserver 本身只是提供了原始时间点，但这些时间点是不是能直接代表真实用户体验，要看你有没有做校准。

比如 SDK 很可能不是最早初始化的，所以像 FCP、LCP 这种早期指标要用 buffered: true 补采。再比如 CLS 不能把所有 layout shift 直接相加，而是要过滤用户主动输入触发的位移，并按 session window 计算。还有像后台打开页面、prerender、bfcache 恢复这些场景，如果不结合 firstHiddenTime、activationStart 或 pageshow persisted 去修正，数据会明显失真。

所以我会把性能监控理解成四层：指标采集、数据校准、上报链路和归因分析。真正能拉开差距的，其实是中间那层数据校准。

监控准确性 2 到 3 分钟

Web 性能监控这个题，很多人都会讲 PerformanceObserver、Web Vitals，但面试官真正继续追问的时候，通常会落到“你怎么保证数据准确”。

我的理解是，性能监控至少分四层。第一层是指标选择，你到底采哪些指标，比如 FCP、LCP、CLS、TTFB，必要时补 INP。第二层是原始采集，也就是基于 PerformanceObserver 和 PerformanceEntry 去监听 paint、largest-contentful-paint、layout-shift、navigation。第三层是数据校准，这一层最关键。第四层才是上报和后续分析。

为什么我说数据校准最关键？因为浏览器给你的原始时间点，并不天然等于真实用户体验。比如 SDK 可能初始化得比较晚，如果不加 buffered: true，FCP、LCP 这种早期指标就会漏。CLS 也不能把所有布局偏移简单累加，因为用户主动输入导致的偏移不应该算进去，所以要看 hadRecentInput，同时按 session window 去做累计。

再比如 FCP、LCP 还要考虑页面是不是在后台打开，是不是 prerender，是不是从 bfcache 恢复。这些场景下浏览器生命周期和真实可见时间并不一致，所以我会结合 firstHiddenTime、activationStart、pageshow persisted 去修正时间基准。还有像 navigation timing 里的 responseStart，我也不会盲信，通常会先做有效性判断，过滤掉明显异常值。

另外我一般不会只上报一个数值，而会尽量补一点归因信息。比如 LCP 我会继续拆成是后端慢、资源慢，还是渲染慢；CLS 我会带最大位移来源和发生时机。这样采回来的数据不只是能看，还能支持定位。

所以如果让我总结，性能监控准确性不是一个 API 问题，而是一个数据校准和场景修正问题。不会校准，采再多也只是脏数据。

最后一句收尾

所以如果让我讲前端监控 SDK，我会把它讲成一套前端观测基础设施：核心抽象、环境适配、插件扩展、稳定上报，这四件事比单点采集技巧更重要。