前端线上错误监控：从「白屏没人知道」到 5 分钟定位的 4 步落地

结论先行

前端线上稳定性最大的坑，不是「没监控」，而是监控了但报错对不上号：拿到一条 TypeError: Cannot read properties of undefined，既不知道哪个页面、哪个版本、哪个用户，也没法复现。我在 3 年里把一套错误监控从 0 搭起来，核心是下面 4 步，每步都有具体做法和踩坑。

第 1 步：把「采集点」分清楚，别只挂 window.onerror

window.onerror + unhandledrejection 只能抓到「逃逸到顶层」的错，React/Vue 组件内部抛错、异步 callback 里被 try/catch 吞掉的错，它都看不见。我们的做法是三层：

1. 全局：window.onerror + window.addEventListener('unhandledrejection') 兜底；
2. 框架层：React 用 ErrorBoundary、Vue 用 app.config.errorHandler 捕获组件渲染错；
3. 业务层：关键链路（下单、支付、提交）的 API 失败单独打点，带上业务上下文。 踩坑：只挂第 1 层时，某次上线后「订单页白屏率」涨了 4 倍，但错误面板里一条相关报错都没有——因为错误被组件里的 try/catch 静默吞了。补上第 2、3 层后才定位到。

第 2 步：每条上报必须带「可定位」的上下文，这是分水岭

裸报错没用。我们给每条上报强制带 6 个字段：

• release（构建版本 hash）+ env（prod/staging）
• url + referrer（区分入口页）
• uid（脱敏后的会话 id，绝不上报真实用户标识）
• stack（原始堆栈）+ bundleMapUrl（sourcemap 地址，见第 4 步） 踩坑：早期没带 release，一次发版后报错量翻倍，结果发现是旧版本缓存的 JS 和新接口字段对不上，因为新旧版本混跑。补上 release 后，按版本一筛，5 分钟就锁定了是旧版本的问题。

第 3 步：采样与去重，别让监控自己把带宽吃光

全量上报会放大问题：一个死循环报错，单个用户每秒能刷几百条。我们的策略：

• 默认采样率 100%，但同一 errorId（hash(message+stack 前 3 帧+release)）在 60s 内只上报 1 条，后面只累加 count；
• 对 ResizeObserver loop limit exceeded 这类已知噪音，直接黑名单过滤（它一年能贡献我们 30% 的「报错量」，全是假象）；
• 用 navigator.sendBeacon 上报，避免 beforeunload 时请求被截断。 踩坑：一开始用 fetch 上报，页面崩溃时请求发不出去，越是出错的页面越采不到数据。换 sendBeacon 后崩溃场景的上报成功率明显回升。

第 4 步：sourcemap 必须「只存不公开」

上线的 JS 是压缩混淆的，堆栈里全是 webpack-xxx.js:1:23456，人读不了。我们把 sourcemap 上传到内部对象存储（私有桶），上报里只带 bundleMapUrl，排查时后端按需拉取还原。 踩坑（最贵的一次）：早期为了图省事，把 sourcemap 一起发布到 CDN，等于把整个源码结构免费送给爬虫。后来发现一个第三方工具直接能反查我们内部接口命名，被迫紧急下线并改私有桶。sourcemap 永远不要进公开静态资源目录。

数据与结论

落地这套之后，我们的几个指标变化（一个季度内）：

• 线上 P0 级白屏事故的平均定位时间：从「平均 1.5 小时（靠用户截图 + 猜）」降到 5 分钟以内（按 release 筛 + sourcemap 还原）；
• 错误面板「无法定位」的占比：从约 60% 降到 8% 以下；
• 假阳性噪音（ResizeObserver 等）：从淹没真实报错降到可忽略。

一句话：前端监控的价值不在「采到多少」，而在「采到之后能不能在 5 分钟内定位到人/版本/页面」。 把 release、上下文、去重、sourcemap 这四件事做对，比换一个更贵的监控平台有用得多。

（本文数据为某中台业务线一个季度的内部观测，已脱敏，不含任何真实用户标识。）