闭包内直接赋值 window.onerror 会覆盖原有处理器，导致异步错误堆栈失真、source/lineno/colno/stack 等关键字段丢失或错乱，并可能干扰 unhandledrejection 事件流，引发循环上报或错误吞没。
闭包内部直接赋值 window.onerror 不仅会覆盖原有错误处理器，还会因作用域链和执行时机错位，导致异步错误的堆栈、上下文和上报逻辑严重失真。这种写法看似“加了全局监控”，实则制造了隐蔽的追踪污染。
看是否在闭包内重写了 window.onerror
重点检查模块初始化、插件加载或工具函数中是否存在类似结构：
function initMonitor() { window.onerror = function() { /* ... */ }; }const plugin = () => { window.onerror = handler; return { destroy: () => delete window.onerror }; };- 第三方 SDK 的 setup 方法里隐式绑定了自己的
onerror，且未做防覆盖保护
只要 window.onerror 被闭包函数内部重新赋值，就脱离了原始注册时的上下文，后续所有错误都会走这个新 handler——而它可能缺失 source 映射、采样控制、跨域处理等关键逻辑。
观察错误日志中是否丢失关键字段或出现错乱时间戳
正常 window.onerror 回调应稳定提供 message、source、lineno、colno 和 error 对象。若发现以下现象，大概率是被闭包内 handler 干扰：
- 同一错误反复上报，但
lineno总是0或undefined -
source字段固定为某个模块路径（如monitor.js），而非真实出错文件 - 多个不同来源的错误共用同一个
error.stack，或 stack 完全为空 - 异步错误（如
setTimeout抛出）的colno比同步错误小很多，明显不符合实际列位置
验证是否破坏了 unhandledrejection 的协同机制
window.onerror 本身不捕获 Promise 拒绝，必须靠 unhandledrejection 补充。但若闭包内 handler 错误地调用了 event.preventDefault() 或返回 true，可能意外影响事件流（尤其在旧版浏览器中）。更常见的是：该 handler 里手动抛出了新错误，又没 catch，导致二次触发 onerror，形成循环上报。可临时加断点验证：
- 在疑似闭包 handler 第一行加
debugger，触发任意 Promise 拒绝（如Promise.reject(new Error('test'))） - 观察是否进入该断点——若进入，说明它劫持了本不该由它处理的事件
- 再检查控制台是否有 “
Uncaught (in promise)” 提示被吞掉或重复打印
用 DevTools 的 Event Listener Breakpoints 快速定位源头
Chrome DevTools → 右上角 ⋯ → More Tools → Developer Tools Settings → Preferences → Events → 勾选 Error 类别。然后重现一次错误：
- 若断点停在某个闭包函数内部（如
init.js:42中的匿名函数），而非你预期的主监控入口，说明该闭包已接管 error 处理 - 查看 Call Stack，确认顶层是否来自
Function.prototype.bind或立即执行函数（IIFE），这是典型闭包注入痕迹 - 在 Console 执行
getEventListeners(window).error，若返回数组长度 > 1，且其中一项是closure类型，基本可锁定问题模块
