前端监控概览

🎯 引言

本地开发时，报错就躺在你的 Console 里；代码上线后运行在用户的设备上，出了问题你却看不见。前端监控解决的就是「线上发生了什么，我能及时知道」。

学完本篇，你将能够：

• 说清楚为什么前端需要监控。
• 说出监控体系的四大方向：错误采集、埋点上报、性能上报、日志告警。
• 写一个简陋但可用的监控脚本，理解「采集 → 上报」这条核心链路。
• 明确本课程六篇的学习路径。

🧱 为什么需要前端监控

本地能看到报错，是因为代码跑在你自己的浏览器里。线上代码跑在成千上万的陌生设备上，这些环境你本地模拟不全，于是产生三个典型痛点：

• 问题无法复现：用户报障只有一句「白屏了」，问题可能只出现在他的设备、网络和操作路径上。
• 反馈严重滞后：多数用户遇到 bug 不会反馈，直接关掉页面走人。
• 优化没有依据：不知道真实用户哪里慢，优化只能凭感觉猜。

没有监控的线上项目，就像一家没有摄像头和收银记录的便利店：东西丢了不知道，什么时候丢的、丢了多少也不知道。监控就是摄像头加账本：出了什么事、影响了多少人、在哪个环节，都有记录可查。

有同学会问：已经有测试了，为什么还要监控？测试在发布前用预设的环境和用例验证代码，监控在发布后观察真实用户的真实环境。两者互补：测试拦住能预见的问题，监控兜住漏掉的问题。

🧱 监控体系的整体面貌

业界主流的监控体系包含四个方向，每个方向回答一类问题：

错误采集：盯着 JS 运行时报错、Promise 未处理的异常、资源加载失败，出错时记录错误信息、位置和用户环境。它直接关系到功能可用性，是体系里优先级较高的一块。

埋点上报：「埋点」是在代码里预先埋下的记录点：用户点了「立即购买」记一条，进入支付页记一条。汇总起来就是产品的点击流和转化漏斗。

性能上报：把真实用户设备上的性能数据（如 Web Vitals）采集上来。指标概念和 web-vitals 用法见 性能优化课程，本课程只讲怎么把数据持续、自动地从线上收上来。

日志与告警：采集的数据需要平台汇总展示，还需要通知机制：错误量飙升时自动提醒值班同学，而不是等用户投诉。这一部分我们会接入开源平台 Sentry。

🛠 动手试试：一个简陋的监控脚本

监控的本质就两步：在浏览器里采集数据，把数据上报到服务器。下面不用任何第三方库，写一个迷你脚本跑通这条链路。浏览器提供了现成的采集入口：JS 运行时报错触发 error 事件，Promise 异常没人 catch 触发 unhandledrejection 事件：

// 采集：监听 JS 运行时报错
window.addEventListener('error', (event) => {
    report({
        type: 'error',
        message: event.message, // 错误信息
        file: event.filename, // 出错的文件
        line: event.lineno, // 出错的行号
    });
});

// 采集：监听没有 catch 的 Promise 异常
window.addEventListener('unhandledrejection', (event) => {
    report({
        type: 'promise-error',
        message: String(event.reason),
    });
});

// 上报：把数据发送到自己的服务器接口
function report(data) {
    navigator.sendBeacon('/api/monitor', JSON.stringify(data));
}

上报用 navigator.sendBeacon 而不是 fetch：监控上报经常发生在页面即将关闭的时刻，普通请求可能被浏览器取消，而 sendBeacon 把数据交给浏览器排队发送，页面关闭后也尽力送达。

引入脚本后故意写一行错误代码，就能验证整条链路：

import './monitor.js';

// 故意触发一个报错，模拟线上事故
const user = null;
console.log(user.name);

在服务器接口的接收日志里（本地可用任意后端框架写个打印接口），就能看到一条带错误信息、文件名和行号的记录。真实项目的监控系统只是在此之上补充更全的采集维度、更稳的上报策略（批量、重试）和展示后台。

🧭 本课程的学习路径

本课程共六篇，按「原理先行、实践跟上」的顺序安排：

1. 前端监控概览（本篇）：监控解决什么问题、体系由哪几块组成。
2. 错误采集：error、unhandledrejection、资源加载错误、框架错误边界的采集。
3. 埋点与数据上报：埋点设计、手动与无痕埋点的区别、上报时机。
4. 性能数据上报：把真实用户的 Web Vitals 等数据自动采集上报，形成性能看板。
5. Sentry 接入实践：接入开源平台 Sentry，体验错误聚合、Source Map 定位等能力。
6. 日志与告警：数据汇总成日志体系，配置告警规则。

🧾 小节总结

• 前端监控解决的核心问题：代码运行在用户设备上，线上发生了什么要及时知道。
• 典型痛点有三个：问题无法复现、用户反馈滞后、优化没有依据。
• 监控体系四大方向：错误采集（代码坏没坏）、埋点上报（用户干了什么）、性能上报（页面快不快）、日志告警（数据怎么变成行动）。
• 监控的本质链路是「采集 → 上报」：error 和 unhandledrejection 是采集入口，sendBeacon 保证页面关闭时数据也能送达。
• 实际工作常用「Sentry 等平台 + 少量自研埋点」的组合。

❓ 知识问答

Q1：本地开发 Console 就能看到报错，为什么还要线上监控？

A：本地看到的是你自己这一次运行的结果。线上大量错误只出现在特定设备、网络或操作路径下，本地复现不了，只能靠监控收集上来。

Q2：监控会不会拖慢我的页面？

A：合理的监控开销很小：采集只是挂事件监听，上报用 sendBeacon 不占主线程。要注意的是「过度监控」：无差别全量上报既浪费带宽又给服务器增压，生产方案通常有采样和批量策略。

Q3：个人小项目也需要监控吗？

A：需要，但可以很轻。至少挂一个错误采集（自己写几行，或直接接 Sentry 免费套餐），否则线上白屏了你可能几个星期都不知道。

Q4：监控采集的数据会不会涉及用户隐私？

A：会有这个风险，采集时就要规避：不采集密码、身份证号等敏感输入，上报前做数据脱敏，并在隐私政策中说明采集范围。

🧪 小练习

练习一：补全下面的监控脚本，让它额外监听图片、脚本等资源加载失败（提示：资源加载错误也触发 error 事件，但发生在捕获阶段，且 event.target 是出错的元素）：

// 请在这里编写代码：监听资源加载失败并上报，注意 addEventListener 的第三个参数

function report(data) {
    navigator.sendBeacon('/api/monitor', JSON.stringify(data));
}

练习二：给「埋点」热身。补全代码，让用户点击登录按钮时上报一条埋点数据，包含事件名 login_click 和点击时的时间戳：

const loginBtn = document.querySelector('#login-btn');

// 请在这里编写代码：点击按钮时上报 { event: 'login_click', time: 时间戳 }

完成后想想：这两条数据和前面采集的报错数据，回答的问题有什么不同？

🎉 恭喜你已经了解前端监控的整体面貌啦！下一篇进入《错误采集》，把 error、unhandledrejection 这些监听手段逐个吃透。