为什么程序员痴迷于错误信息上报？
前言
上一篇已经聊过日志上报的调度原理，讲述如何处理日志上报堆积、上报失败以及上报优化等方案。
从上家公司开始，监控就由我们组身强体壮的同事来负责，而我只能开发Admin和H5；经过一系列焦虑的面试后，咸鱼翻身，这辈子我也做上监控了。千万不要以为我是因为监控的重要性才这么执着，人往往得不到的东西才是最有吸引力的。
在写这篇文章时，我也在思考，为什么走到哪里都会有一群程序员喜欢封装监控呢？即使换个公司、换个组，依然可能需要有人来迭代监控。嗯，话不多说，先点关注，正文开始。
错误监控的核心价值
如果让你封装一个前端监控，你会怎么设计监控的上报优先级？
对于一个网页来说，能否带给用户好的体验，核心指标就是 白屏时长 和 FMP时长，这两项指标直接影响用户的 留存率 和 体验。
下面通过数据加强理解：
- 白屏时间 > 3秒 导致用户流失率上升47%
- 接口错误率 > 0.5% 造成订单转化率下降23%
- JS错误数 > 1/千次访问 预示着系统稳定性风险
设想一下，当你访问页面时白屏等待了3秒，并且页面没有骨架屏或者Loading态时，你会不会觉得这个页面挂了？这时候如果我们的监控优先关注的是性能，可能用户已经退出了，我们的上报还没调用到。
在这个白屏等待的过程中，JS Error可能已经打印在控制台了，接口可能已经返回了错误信息，但是程序员却毫无感知。
优先上报错误信息，本质是为了提升生产环境的错误响应速度、减少生产环境的损失、提高上线流程的规范。以下是错误响应的黄金时间轴：
| 时间窗口 | 响应动作 | 业务影响 |
|---|---|---|
| < 1分钟 | 自动熔断异常接口 | 避免错误扩散 |
| 1-5分钟 | 触发告警通知值班人员 | 降低MTTR（平均修复时间） |
| >5分钟 | 生成故障诊断报告 | 优化事后复盘流程 |
重要章节
一：错误类型，你需要关注的五大场景
技术本质：任何错误收集系统都需要先明确错误边界。前端错误主要分为两类： 显性错误（直接阻断执行）和 隐性错误（资源加载、异步异常等）。
// 显性错误（同步执行阶段）
function criticalFunction() {
undefinedVariable.access(); // ReferenceError
}
// 隐性错误（异步场景）
fetchData().then(() => {
invalidJSON.parse(); // 异步代码中的错误
});
关键分类： 通过错误本质将前端常见错误分为5种类型，图示如下。 
- 语法层错误（SyntaxError）
ESLint 可拦截，但运行时需注意动态语法（如eval，这个用法不推荐）。 - 运行时异常
错误的时机场景大部分是在页面渲染完成后，用户对页面发生交互行为，触发JS执行异常。以下是模拟报错的一个例子，用于学习。 // 典型场景 element.addEventListener('click', () => { throw new Error('Event handler crash'); }); - 资源加载失败
常见的资源比如图片、JS脚本、字体文件、外链引入的三方依赖等。我们可以通过全局监听处理，比如使用document.addEventListener('error', handler, true)来捕获资源加载失败的情况。但需要注意以下几点：、
