前端错误监控需捕获同步、异步及资源加载错误，核心手段是组合使用window.onerror、addeventlistener('error')和unhandledrejection事件，弥补try...catch无法覆盖异步和资源错误的局限；捕获后需上报错误堆栈及上下文信息，如用户id、url、浏览器环境、操作路径（breadcrumbs）、应用状态和网络请求等，以便精准定位问题。采用第三方监控服务可提升效率与覆盖度。
前端错误监控的核心，说白了，就是要在用户遇到问题时，我们能第一时间知道，并拿到足够的信息去定位和解决。它不仅仅是捕获
try...catch漏掉的异常，更像是在应用里安插了无数个“眼睛”，盯着任何可能出岔子的地方，然后把“案发现场”的证据收集起来，悄悄汇报给我们。这套机制，是保证前端应用稳定性和用户体验的最后一道防线，也是我们日常开发中，从“能跑”到“跑得稳”的关键一步。
解决方案
利用JavaScript进行前端错误监控，我们通常会组合多种策略。首先是全局错误捕获，这是基石。
window.onerror和
window.addEventListener('error', ...)是捕获脚本运行时错误和资源加载错误的利器。onerror能捕获到未被
try...catch处理的同步错误，以及一些资源加载错误（比如图片或脚本加载失败），但它对跨域脚本的错误信息会有所限制（只显示"Script error."）。而
addEventListener('error', ...)则能提供更详细的错误对象，甚至可以捕获到冒泡的资源错误事件。
对于异步操作，特别是Promise链中未被
.catch()处理的拒绝，
window.addEventListener('unhandledrejection', ...)就显得尤为重要了。很多现代前端框架和库大量使用Promise，如果一个Promise被拒绝了，但你没有显式地处理它，它就会变成一个“未捕获的拒绝”，这通常意味着应用逻辑出现了问题，但又不会直接抛出同步错误，容易被忽略。// 全局错误捕获
window.onerror = function(message, source, lineno, colno, error) {
console.error('Caught by window.onerror:', { message, source, lineno, colno, error });
// 在这里将错误信息上报到后端或监控服务
// reportErrorToService({ type: 'js_error', ... });
return true; // 返回true阻止浏览器默认的错误处理
};
// 更细粒度的错误捕获，可以捕获到资源加载错误等
window.addEventListener('error', function(event) {
// 检查event.target，区分是JS错误还是资源加载错误
if (event.error) { // JS运行时错误
console.error('Caught by addEventListener("error"):', event.error);
// reportErrorToService({ type: 'js_runtime_error', ... });
} else if (event.target && event.target !== window) { // 资源加载错误
console.error('Resource loading error:', event.target.src || event.target.href);
// reportErrorToService({ type: 'resource_load_error', url: event.target.src || event.target.href, ... });
}
// 阻止浏览器默认行为
event.preventDefault();
}, true); // 使用捕获阶段，确保能捕获到所有错误
// 捕获Promise未处理的拒绝
window.addEventListener('unhandledrejection', function(event) {
console.error('Unhandled Promise Rejection:', event.reason);
// reportErrorToService({ type: 'promise_rejection', reason: event.reason, ... });
event.preventDefault(); // 阻止浏览器控制台默认打印
});
// 对于同步代码块，仍然可以使用try...catch
function riskySyncOperation() {
try {
// 可能会抛出错误的代码
throw new Error('This is a synchronous error.');
} catch (e) {
console.error('Caught by try...catch:', e);
// reportErrorToService({ type: 'sync_error_handled', ... });
}
}
riskySyncOperation();捕获到错误后，下一步就是上报。上报时，除了错误本身的堆栈信息（
error.stack），我们还需要附带尽可能多的上下文信息，比如当前页面URL、用户ID、浏览器信息（User-Agent）、操作路径（breadcrumbs）、甚至网络请求情况等等。这些信息是排查问题的关键。上报方式可以是简单的
XMLHttpRequest或
fetch发送到后端API，也可以是集成专业的第三方监控SDK（如Sentry、Bugsnag、Fundebug等），它们通常提供了更完善的错误聚合、去重、报警和上下文收集能力。我个人倾向于在项目初期就引入成熟的第三方服务，能省去很多自己造轮子的麻烦。
立即学习“Java免费学习笔记（深入）”；
为什么传统的try...catch
对前端监控不够用？
说实话，刚开始接触前端监控的时候，我也会想，不是有
try...catch吗？把所有可能出错的代码都包起来不就行了？但实际操作起来，你会发现这根本不现实。
try...catch的局限性太大了，它主要针对的是同步代码块中抛出的异常。一旦代码进入异步流程，比如
setTimeout的回调函数、
Promise链中的
.then()或
.catch()里抛出的错误，甚至是用户事件监听器里的错误，
try...catch就鞭长莫及了。
想象一下，你在一个
setTimeout里做了一些操作，结果报错了，外层的
try...catch是捕获不到的。再比如，一个图片加载失败了，或者一个外部脚本加载出错，这些都不是JavaScript代码运行时直接抛出的错误，
try...catch也无能为力。更别提那些在事件循环中，浏览器内部抛出的全局性、未处理的错误了。所以，如果只依赖
try...catch，你的监控系统将会有大量的“盲区”，很多真实的用户问题根本无法被发现。它更适合用来处理特定、可预期的同步异常，而不是作为全局的错误兜底方案。
如何捕获异步错误和资源加载失败？
捕获这些“漏网之鱼”才是前端监控的挑战所在。对于异步错误，尤其是Promise相关的，
window.addEventListener('unhandledrejection', ...)是你的救星。它能监听所有未被catch处理的Promise拒绝，这在现代JavaScript应用中非常常见，因为Promise已经成了异步编程的主流。当一个Promise被拒绝，并且没有任何
.catch()来处理它时，这个事件就会被触发，你就能拿到错误信息了。
资源加载失败，比如一个
@@##@@标签的
src指向了一个不存在的图片，或者
<script>标签加载的JS文件404了，这些错误不会通过
try...catch抛出。这时候，
window.addEventListener('error', ...)就派上用场了。这个事件不仅能捕获到JS运行时错误，当资源（如图片、脚本、样式表）加载失败时，它也会被触发。你可以在事件对象中检查event.target来判断是哪种类型的错误。比如，如果
event.target是一个
@@##@@元素，那很可能就是图片加载失败了。不过，要注意跨域脚本的错误，浏览器出于安全考虑，通常只会给你一个笼统的"Script error."，不会暴露详细的错误堆栈。解决这个问题通常需要目标脚本服务器设置正确的CORS响应头（
Access-Control-Allow-Origin）。
// 捕获Promise未处理的拒绝
// 比如：
new Promise((resolve, reject) => {
setTimeout(() => {
reject('Something went wrong asynchronously!'); // 这个拒绝没有被.catch()处理
}, 100);
});
// 捕获资源加载失败
// 比如一个不存在的图片：
const img = document.createElement('img');
img.src = 'https://example.com/non-existent-image.jpg';
document.body.appendChild(img);
// 此时，如果图片加载失败，window.addEventListener('error', ...) 会捕获到
// 对于跨域脚本的错误，如果服务器没有设置CORS，可能会是"Script error."
// <script src="https://another-domain.com/bad-script.js"></script>
// 如果bad-script.js里有错误，且another-domain.com没有设置CORS头，
// window.onerror 或 addEventListener('error') 将只会得到 "Script error."所以，真正要做到全面监控，需要将这些全局监听器组合起来，形成一个“天罗地网”，确保无论是同步、异步还是资源加载的错误，都能被有效地捕获。
错误上报时，除了错误信息我们还需要什么上下文？
光有错误信息，很多时候是抓瞎的。想象一下，你收到一条错误报告：“TypeError: Cannot read property 'name' of undefined”，然后就没了。你会怎么排查？哪个页面？哪个用户？在做什么操作？哪个版本？这些信息缺失，排查起来简直是大海捞针。所以，错误上报时，除了最基本的错误类型、错误消息和堆栈信息，我们还需要附带一系列的上下文数据，这些数据能帮助我们快速还原“案发现场”。
我个人觉得，最重要的几点包括：
- 用户和环境信息： 当前登录的用户ID（如果存在）、浏览器型号、操作系统、设备类型（PC/移动）、当前页面的URL、User-Agent字符串。这些能帮助我们判断是特定用户、特定环境才出现的问题。
- 操作路径（Breadcrumbs）： 用户在出错前都做了什么？点击了哪些按钮？访问了哪些路由？这些“面包屑”信息能像录像一样，重现用户操作流程，定位到触发错误的具体步骤。
- 应用状态： 错误发生时，应用的关键状态是什么？比如某个组件的props或state，或者全局store中的关键数据。这对于理解错误发生时的业务逻辑至关重要。
- 网络请求： 错误发生前后的网络请求情况，有没有某个API请求失败了？请求参数和响应体是什么？很多前端错误其实是后端API异常的连锁反应。
- 自定义标签/元数据： 可以根据业务需求添加一些自定义的标签，比如当前应用的模块名称、版本号、A/B测试组等，方便后续对错误进行分类和筛选。
- 时间戳： 错误发生的确切时间，方便与后端日志进行关联排查。
举个例子，一个好的错误报告可能会是这样：
{
"errorType": "TypeError",
"errorMessage": "Cannot read property 'name' of undefined",
"stackTrace": "at someFunction (http://example.com/app.js:123:45)",
"timestamp": "2023-10-27T10:30:00Z",
"url": "http://example.com/products/detail/123",
"userId": "user_abc",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36",
"breadcrumbs": [
{"type": "navigation", "message": "/home -> /products"},
{"type": "click", "message": "Clicked product item with id 123"},
{"type": "api_request", "message": "GET /api/product/123 status: 200"}
],
"appVersion": "1.2.0",
""componentState": {"productId": 123, "isLoading": false}
}这些丰富的信息，能让一个模糊的错误变得清晰起来，大大提高我们排查和解决问题的效率。所以，在设计错误上报机制时，一定要多花心思在上下文信息的收集上。
