window.onerror是JavaScript提供的全局错误捕获接口，能够监听页面中未被try-catch捕获的运行时错误，是前端错误监控体系的核心组成部分。很多开发者在接入错误监控时都会优先使用这个接口，但实际使用过程中会遇到各种不符合预期的情况。
window.onerror的基本用法
window.onerror是一个全局事件处理函数，当页面发生未被捕获的JavaScript错误时会被触发，它接收五个参数，分别是错误信息、错误发生的文件URL、错误所在的行号、错误所在的列号、错误对象。基本使用方式如下：
// 定义window.onerror处理函数
window.onerror = function(message, source, lineno, colno, error) {
// 打印捕获到的错误信息
console.log('错误信息:', message);
console.log('错误文件:', source);
console.log('错误行号:', lineno);
console.log('错误列号:', colno);
console.log('错误对象:', error);
// 这里可以添加上报错误到监控服务的逻辑
return true; // 返回true可以阻止默认的错误提示
};
window.onerror拦截的常见陷阱
1. 跨域脚本错误无法获取详细信息
如果页面中引入了跨域的JavaScript脚本，当这个脚本发生错误时，window.onerror捕获到的message会是Script error.，source、lineno、colno等信息都会是undefined，这是浏览器的同源策略导致的。很多开发者第一次遇到这种情况会以为是自己的拦截逻辑写错了，实际上是跨域限制的问题。
2. 部分错误类型无法被捕获
window.onerror并不能捕获所有类型的错误，比如网络请求错误、资源加载错误（如图片、脚本加载失败）、Promise未被拒绝的错误，这些错误都不会触发window.onerror。如果需要捕获资源加载错误，需要额外监听window的error事件，并且判断事件的目标是否是元素节点。
3. 重复定义会覆盖之前的拦截逻辑
window.onerror是一个函数属性，如果多次赋值，后面的定义会覆盖前面的。如果项目中多个模块都单独定义了window.onerror，那么只有最后一个定义会生效，之前的拦截逻辑都会失效，很容易导致错误监控数据丢失。
4. 错误对象信息可能不完整
在一些老版本的浏览器中，window.onerror的第五个参数error可能不存在，或者error对象的stack属性为空，这时候就无法获取到完整的错误堆栈，给错误排查带来困难。另外如果错误是语法错误，在部分场景下也可能无法获取到完整的堆栈信息。
5. 返回值的影响
window.onerror的返回值会影响浏览器是否显示默认的错误提示，如果返回true，浏览器不会显示默认的错误弹窗或者控制台提示；如果返回false或者不返回，浏览器会显示默认的错误提示。如果是在生产环境，通常需要返回true避免用户看到错误提示，但开发环境可能需要保留默认提示方便调试。
window.onerror的最佳实践
1. 处理跨域脚本错误
对于跨域引入的脚本，需要在script标签上添加crossorigin属性，同时服务器需要返回正确的CORS响应头，允许跨域访问，这样window.onerror才能获取到完整的错误信息。示例如下：
<!-- 跨域脚本添加crossorigin属性 --> <script src="https://static.ipipp.com/js/app.js" crossorigin="anonymous"></script>
服务器端需要返回的响应头包含Access-Control-Allow-Origin，值可以是具体的域名或者*，根据实际场景配置即可。
2. 避免重复定义，使用事件监听方式
为了避免多个模块定义window.onerror互相覆盖，可以使用addEventListener监听error事件，这种方式可以添加多个监听函数，不会互相覆盖。示例如下：
// 使用addEventListener监听全局错误
window.addEventListener('error', function(event) {
// 区分是资源加载错误还是JS运行时错误
if (event.target && (event.target.tagName === 'IMG' || event.target.tagName === 'SCRIPT')) {
// 资源加载错误的处理逻辑
console.log('资源加载失败:', event.target.src || event.target.href);
} else {
// JS运行时错误的处理逻辑
console.log('JS错误:', event.message);
console.log('错误文件:', event.filename);
console.log('错误行号:', event.lineno);
console.log('错误列号:', event.colno);
console.log('错误堆栈:', event.error && event.error.stack);
}
}, true); // 使用捕获阶段监听，确保能拿到所有错误
3. 补充捕获Promise错误
为了捕获未被处理的Promise错误，需要额外监听unhandledrejection事件，这个事件会在Promise被拒绝且没有对应的catch处理时触发。示例如下：
// 监听未处理的Promise拒绝错误
window.addEventListener('unhandledrejection', function(event) {
console.log('未处理的Promise错误:', event.reason);
// 这里可以添加错误上报逻辑
event.preventDefault(); // 阻止默认的控制台错误提示
});
4. 错误信息的兼容处理
在获取错误信息时，需要做兼容处理，避免因为浏览器不支持某个属性导致报错。比如先判断error对象是否存在，再获取stack属性，对于拿不到详细信息的Script error，可以做特殊标记，避免影响错误统计。示例如下：
window.addEventListener('error', function(event) {
let errorInfo = {
message: event.message || '未知错误',
source: event.filename || '',
lineno: event.lineno || 0,
colno: event.colno || 0,
stack: ''
};
// 兼容处理错误堆栈
if (event.error && event.error.stack) {
errorInfo.stack = event.error.stack;
} else {
errorInfo.stack = '无堆栈信息';
}
// 处理跨域脚本错误
if (errorInfo.message === 'Script error.') {
errorInfo.message = '跨域脚本错误，无详细信息';
}
// 上报错误逻辑
console.log('处理后的错误信息:', errorInfo);
});
5. 区分开发和生产环境配置
开发环境下可以保留默认的错误提示，方便调试，不需要返回true阻止默认行为；生产环境下返回true阻止默认提示，同时做好错误上报，避免用户看到不友好的错误提示。可以通过环境变量来区分环境，动态调整配置。
总结
window.onerror是前端全局错误拦截的重要工具，但使用时需要充分了解它的特性和限制，避开常见的陷阱。通过合理的配置，结合其他错误监听事件，能够构建更完善的前端错误监控体系，帮助开发者快速定位和解决问题，提升页面的稳定性和用户体验。
window.onerrorJavaScript错误拦截前端监控修改时间：2026-07-16 14:42:36