我为什么把“前端异常监控”从“可有可无”变成了“上线必配”

以前我做后端，眼里只有接口、数据库、服务器。前端？那是前端同学的事。页面白屏了、按钮点了没反应、接口报错了用户不知道——跟我有什么关系？

直到有一次，客服转过来一条用户反馈：“你们那个页面，点提交没反应，我试了十几次都不行。”我查了半天接口日志，发现压根没收到请求。让前端同学帮忙看，他说本地复现不了。最后怎么定位的？用户截图过来，我们才发现是某个 JS 文件加载失败，整个页面逻辑直接挂了。而我们对这个“挂”，一无所知。

那次之后，我在项目里强制接入了前端异常监控，现在回头看，这是这几年做得最值的一个决定。

一、你不知道的“沉默错误”有多少

接入监控第一周，告警面板上的数字让我震惊：每天有 3000+ 条 JS 异常，其中 80% 我们完全不知道。

分类一看，触目惊心：

• 资源加载失败：CDN 某个节点抖动，JS/CSS 文件 404，页面直接白屏
• 接口超时：后端响应超过 10 秒，前端 Promise 没 catch，直接 UnhandledRejection
• 类型错误：Cannot read properties of undefined，某个字段后端偶尔返回 null，前端没判空
• 兼容性问题：某用户的手机浏览器不支持某个 ES6 特性，直接语法错误

这些问题有一个共同点：用户感知到了，我们感知不到。 用户只会觉得“这破网站又卡了”，然后关掉走人。你连修复的机会都没有，因为根本不知道发生了什么。

二、监控不是只记个错误名，要能还原现场

最开始我们只是 window.onerror 抓一下错误信息，发现根本不够用。后来换成了 Sentry，它能自动采集：

• 错误堆栈：精确到哪一行哪一列
• 用户环境：浏览器、OS、设备型号、网络类型
• 操作轨迹：报错前用户点了什么、跳了哪些页面
• 请求上下文：报错时发了哪些接口、返回了什么

有一次一个用户反馈“支付完页面没跳转”。我在 Sentry 里搜到对应的错误，发现是支付回调页面里调用了一个 getOrderDetail 接口，这个接口偶现 500，前端没做错误处理，Promise 链断了，后续跳转逻辑没执行。堆栈、接口返回、用户设备，一目了然。从发现到修复，20 分钟。

如果没有监控，这个 Bug 可能要用户反复反馈、客服反复转述、开发反复猜，最后花两天才能定位。

三、三个最容易漏的“前端错误类型”

1. 接口错误没被 catch

这是最高频的。前端同学写 fetch 或 axios 时，经常只处理成功回调，忘了 .catch()：

// ❌ 危险写法
fetch('/api/order/create', { method: 'POST' })
  .then(res => res.json())
  .then(data => { /* 处理成功 */ });
// 如果接口 500，这里什么都不会发生，用户看到的就是"没反应"

// ✅ 正确写法
fetch('/api/order/create', { method: 'POST' })
  .then(res => res.json())
  .then(data => { /* 处理成功 */ })
  .catch(err => {
    Sentry.captureException(err);
    showToast('下单失败，请重试');
  });

2. 资源加载失败

JS、CSS、图片加载失败，很多人不知道可以监控：

window.addEventListener('error', (e) => {
  if (e.target !== window) {
    // 资源加载错误（img, script, link）
    Sentry.captureMessage(`Resource failed: ${e.target.src || e.target.href}`);
  }
}, true); // 注意：资源错误要用捕获阶段

3. 未处理的 Promise 拒绝

window.addEventListener('unhandledrejection', (e) => {
  Sentry.captureException(e.reason);
});

这两行代码，帮我们抓到了无数个"静默失败"。

四、告警分级：别让噪音淹没信号

监控接上后，告警太多也是问题。我们做了分级：

• P0：页面白屏（JS 加载失败、首屏渲染报错）→ 立刻告警
• P1：核心流程阻断（下单、支付、登录报错）→ 15 分钟内处理
• P2：非核心功能异常（分享、评价、个性化推荐）→ 记录工单

关键是设告警阈值：同一个错误 5 分钟内出现超过 50 次才告警，避免个别用户的偶发问题刷屏。

五、一个意外收获：监控帮我们发现了后端问题

最让我意外的是，前端监控经常帮我们定位后端 Bug。

比如有一次 Sentry 里突然出现大量 TypeError: Cannot read property 'price' of null，追查发现是商品详情接口在某个条件下返回了 null 而不是空对象。后端同学查日志根本没发现，因为接口返回的是 200，只是数据结构不对。

前端监控成了我们系统的"终端探针"——离用户最近的地方，最先感知到问题。

一个心态的转变

以前我觉得前端监控是"锦上添花"，现在觉得是上线前的最后一道防线。后端有日志、有监控、有告警，前端凭什么裸奔？用户最终用的是页面，页面出了问题，你连知道都不知道，还谈什么修复？

如果你现在的项目还没有前端异常监控，今晚就花半小时接一个 Sentry 或类似工具。不用配得很复杂，先把 window.onerror 和 unhandledrejection 接上。你会发现一个全新的世界——原来你的系统有这么多"沉默的错误"在悄悄流失用户。

毕竟，用户不会给你报 Bug，他们只会默默离开。