只监听 window.onerror 会漏掉 70% 的真实故障，因其无法捕获资源加载失败、嵌套 Promise 拒绝、SSR/CSR 混合白屏三类高频异常，且缺乏用户操作上下文导致无法复现。
window.onerror 和 unhandledrejection 不够用，必须补全资源加载、白屏、接口异常、用户操作上下文这五类信号，否则告警漏报率会超过 40%。
为什么只监听 window.onerror 会漏掉 70% 的真实故障
很多团队上线后发现 Sentry 或 Bugsnag 报的错误远少于用户客诉量，根本原因是只靠 window.onerror 捕获不到三类高频异常：资源加载失败（img、script、link 标签的 onerror）、Promise 拒绝未处理（unhandledrejection 只捕获顶层，嵌套 reject 会静默丢失）、以及 SSR/CSR 混合场景下的白屏（DOM 根节点无内容但 JS 未抛错）。更关键的是，这些错误缺乏用户行为路径（比如“点击支付按钮 → 加载 pay.js 失败 → 页面卡住”），导致无法复现。
实操建议：
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 给所有动态插入的
script和link标签显式绑定onerror回调，上报src+event.target.tagName+event.timeStamp - 用
PerformanceObserver监听resource类型，过滤出initiatorType === 'script'且duration === 0的请求（说明加载失败） - 白屏检测不要只查
document.body.innerHTML，应结合业务约定的“首屏容器 ID”，例如document.getElementById('main-view')?.children.length === 0，并限制检查时机（如DOMContentLoaded后 1.5s）
reportError() 上报前必须做三件事：脱敏、限频、打标
直接把原始 error.stack 或 event.reason 发到服务端，轻则触发敏感信息泄露（如 URL 带 token），重则被刷爆带宽（某个循环报错每秒发 200 条）。线上 SDK 必须内置基础防护。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- URL 脱敏：正则替换
/[?&]token=[^&]+/g→'[REDACTED]'，同时过滤console.error中的密码字段（如password、auth） - 限频策略：对同一
error.message+error.filename组合，10 秒内只允许上报 3 次；超限后改用本地localStorage缓存，下次页面加载时合并上报 - 打标：强制注入
env: 'prod'、version: '1.2.3'、page: location.pathname，避免告警时无法区分灰度流量
告警规则不能写死阈值，得按页面/组件维度动态配置
全站统一设“JS 错误率 > 1%”告警，会导致首页报错被淹没（日均 PV 500 万，1% 就是 5 万条），而管理后台一个错误就该立刻响应（日均 PV 200，1% 才 2 条）。同样，LCP 超过 2.5s 对电商详情页是 P0，对帮助中心页面可能只是 P2。
实操建议：
- 在监控平台配置项里支持路径匹配，例如
/product/.*对应 LCP 阈值 2500ms，/help/.*对应 4000ms - 关键组件单独埋点：React/Vue 组件级
componentDidCatch或errorCaptured钩子中调用reportComponentError({ name: 'PayButton', props: { type: 'wx' } })，告警时能直接定位到组件实例 - 错误聚合维度必须包含
user.id（登录态）和device.type（mobile/desktop），否则 iOS 17.4 下的 Promise.allSettled 兼容问题会被误判为全量故障
钉钉/企微机器人告警里必须带可直达的诊断链接
收到“首页错误率突增至 3.2%”这种消息，第一反应不是看数据，而是打开 Chrome DevTools 切换设备模拟器再手动复现——这浪费至少 8 分钟。真正有效的告警要让人 3 秒内进入分析闭环。
实操建议：
- 每条告警消息末尾拼接诊断 URL，格式为：
https://monitor.example.com/traces?from=2026-04-12T11:00&to=2026-04-12T11:05&filter=page:/home&error=ReferenceError - 链接需预加载最近 5 分钟该页面的 Top 3 错误堆栈 + 对应的用户操作序列（如 “click #search-btn → fetch /api/suggest → network timeout”）
- 如果是 P0 级告警（如支付流程中断），额外在消息头加
@负责人并触发电话外呼（通过第三方语音 API），避免深夜被消息淹没
最常被忽略的一点：前端监控的采样率和后端日志的 traceID 必须对齐。如果前端 10% 采样上报了错误，但后端全量记录了 trace，排查时就会发现“前端说有错，后端日志里找不到对应 traceID”。上线前务必验证 trace_id 字段是否从 fetch 请求 header 透传到了后端，并在 SDK 初始化时校验采样开关与后端配置一致。
