promise异常冒泡终点是unhandledrejection事件，它是集中式错误采集的核心入口；需标准化reason字段、补充上下文、用sendbeacon轻量上报，并与window.onerror等联动实现全链路异常追踪。

Promise 的异常冒泡机制天然适合构建集中式错误采集，关键在于让所有未被捕获的拒绝（rejection）浮出水面，再统一拦截、标准化、上报。它不是靠每个地方都写 .catch()，而是靠“漏掉的错误必须有归处”这一设计原则。

理解冒泡终点：为什么 unhandledrejection 是核心入口

Promise 链中任意环节抛出错误（包括 throw、reject()、返回被拒 Promise），若未被当前链上的 .catch() 或 try/catch 拦截，就会一直向后传递，直到链尾。如果整条链都没有处理，浏览器会触发 unhandledrejection 事件——这就是冒泡的终点，也是监控系统的唯一可靠钩子。

• window.onerror 完全捕获不到这类错误，因为它们发生在微任务队列，与同步执行栈隔离
• 仅监听 unhandledrejection 就能覆盖所有漏网的 Promise 异常，无需修改业务代码逻辑
• 该事件在主流浏览器（Chrome、Firefox、Edge、Safari 11+）均已稳定支持

标准化错误信息：从 reason 中提取可分析字段

事件对象的 reason 属性可能是一个 Error 实例、普通对象、字符串，甚至 undefined。直接上报会导致格式混乱，需做归一化处理：

• 优先取 reason.message 和 reason.stack（若存在且为 Error 实例）
• 否则用 String(reason) 保证内容不为空
• 补充上下文：当前 URL、用户设备 UA、时间戳、页面可见状态（document.visibilityState）
• 标记来源：固定添加 type: "unhandledrejection"，便于后端路由和分类

轻量级上报与容错设计

上报本身不能成为故障点，需兼顾可靠性与性能：

• 使用 navigator.sendBeacon() 发送日志，确保页面卸载时仍能发出请求
• 避免 JSON 序列化失败：对不可序列化的字段（如函数、循环引用）做安全过滤或降级处理
• 本地节流：同一错误 5 分钟内重复发生只上报一次，防止刷屏式日志
• 降级存储：若网络不可用，暂存至 localStorage，页面重入时补发

与全局错误监控联动，形成完整视图

Promise 异常只是前端异常的一类。要真正定位问题，需将其和其它异常关联起来：

• 在 window.onerror 和 unhandledrejection 上报时，共用同一 request ID（如生成 UUID），方便服务端关联同一次用户会话中的多类错误
• 记录前一个页面跳转来源（document.referrer）和当前路由（location.pathname），辅助复现路径
• 结合资源加载失败（error 事件监听 <img>、<script></script>）日志，判断是否由静态资源异常引发后续 Promise 失败