App端全局异常处理必须用uni.onError和uni.onUnhandledRejection，前者捕获同步错误、生命周期抛错等，后者捕获未catch的Promise拒绝，均须在App.vue的onLaunch中注册，且需区分JS异常、网络失败、资源加载失败三类场景。
App端的全局异常处理必须用 uni.onError 和 uni.onUnhandledRejection，不能靠 window.onerror 或 Vue 的 errorHandler；错误重试必须区分 JS 异常、网络请求失败、资源加载失败三类场景，不能统一 reload。
App端必须用 uni.onError 而不是 window.onerror
App端（iOS/Android）运行在原生容器中，window.onerror 根本监听不到同步错误、生命周期抛错、throw 语句等。只有 uni.onError 是 uni-app 框架主动桥接到原生异常通道的唯一入口。
-
uni.onError必须在App.vue的onLaunch中注册，延迟注册会漏掉冷启动阶段的异常 - 它能捕获：Vue 生命周期钩子内抛出的错误、
throw new Error()、uni.navigateTo失败等，但不捕获组件模板渲染错误（如访问 undefined 属性） - 不要在页面里重复注册，否则可能触发多次上报或干扰锁机制
Promise 拒绝必须用 uni.onUnhandledRejection
uni.onUnhandledRejection 是 App 端捕获未 catch 的 Promise 拒绝的唯一可靠方式，包括 async/await 中未包裹 try/catch 的 reject。
- 和
uni.onError一样，必须在App.vue的onLaunch中注册 - 注意：它不捕获已
catch的拒绝，也不捕获被Promise.allSettled吞掉的错误 - 常见误判：把网络请求超时当成“未处理拒绝”——实际应由请求封装层拦截并转为业务错误，而非交由全局拒绝监听兜底
资源加载失败（ChunkLoadError）需单独处理
H5 端的 SyntaxError: Unexpected token ' 或 <code>ChunkLoadError 在 App 端不会出现，但 App 端有类似问题：热更新后旧 JS 文件被移除，却仍尝试加载，导致白屏或功能缺失。这不是 JS 运行时异常，uni.onError 收不到。
- 解决方案是监听
uni.getUpdateManager的更新事件，在新版本下载完成、准备重启前主动 reload - 若已发生加载失败（如分包加载 404），需在请求封装层拦截
uni.loadSubNVue或uni.preloadPage的失败回调，触发降级逻辑（如跳首页、提示重进） - 不要在
uni.onError里对所有错误都调location.reload()，App 端没有location对象，会直接报错
网络请求失败的重试不能依赖全局异常监听
全局异常监听只负责“兜底”，不负责业务重试。网络请求的重试必须下沉到请求封装层，结合状态码、错误类型、重试次数、退避策略来决策。
- 401/403 应触发登录态刷新，不是重试；500/502 可配置指数退避重试；超时或连接失败可立即重试 1–2 次
- 重试逻辑要防重复提交：用
pendingRequestSet 缓存请求标识（url+method+JSON.stringify(data)），避免用户连点触发多条重试请求 - 重试失败后，才交给全局错误处理器统一展示提示（用
uni.showToast而非alert），并记录结构化日志（含当前页面、网络类型、设备型号）
真正容易被忽略的是：App 端原生崩溃（如 iOS 的 EXC_BAD_ACCESS、Android 的 NullPointerException）完全不在 JS 异常体系内，uni.onError 一概收不到。必须额外接入 Bugly 或 UMeng 原生 SDK，并确认已在 manifest.json → App模块配置 中勾选对应插件，否则线上等于没监控。
