必须接入原生SDK（如Bugly、UMeng或uni-crash-report）才能捕获App崩溃，因uni.onError和uni.onUnhandledRejection仅处理JS层错误，无法捕获iOS/Android原生异常。
只靠 uni.onError 和 uni.onUnhandledRejection 捕获不到真正的 App 崩溃（Crash），必须接入原生 SDK —— 这是线上崩溃日志收集的第一道铁律。
为什么 JS 层捕获不了 Crash
App 崩溃本质是原生层异常：iOS 的 EXC_BAD_ACCESS、Android 的 NullPointerException 或 ANR，完全绕过 JS 引擎。uni-app 的 uni.onError 只能抓到 JS 运行时抛出的错误（比如 throw new Error() 或生命周期里报错），对原生崩溃毫无感知。实测数据显示，纯 JS 日志上报覆盖不到 20% 的真实闪退场景。
-
uni.onError在 H5 / 小程序里根本无效，是 App 端专属 API，但依然不处理原生崩溃 - 把
uni.onError写在某个页面的onLoad里？冷启动阶段的异常直接丢失，用户点开就白屏，你收不到任何线索 - 试图用
window.onerror或Vue.config.errorHandler替代？在 App 容器中基本不触发，属于无效努力
必须用原生 SDK：Bugly、UMeng 或 uni-crash-report
真正能采集到崩溃堆栈、线程状态、内存快照的，只有原生 SDK。推荐优先使用已封装好的 uni-app 插件，避免自己写原生模块踩坑。
- 在插件市场搜
uni-crash-report，它已集成 Bugly（Android）和腾讯MTA（iOS），支持自动上报、崩溃归因、版本分布分析 - 必须在
manifest.json → App 模块配置中手动勾选对应 SDK，否则打包后 SDK 不生效 - 初始化必须放在
App.vue的onLaunch里，且不能包裹在异步逻辑中（比如等登录完成再 init），否则首屏崩溃就漏掉 - SDK 上报的日志字段要和 JS 层统一：比如都带
appVersion、deviceModel、osVersion，方便后端关联分析
本地日志文件 + 智能上传策略
原生崩溃日志默认写入私有目录（如 Android/data/[包名]/files/crash_report.txt），但不能只依赖它——用户可能没联网、App 被杀、或日志被系统清理。得自己补一层 JS 侧兜底+协同机制。
- 用
plus.io.requestFileSystem写入_doc/logs/下的独立 crash 文件，命名如crash_2026-10-30_120922.log，避免和业务日志混在一起 - 每次写入前检查文件大小，超 2MB 自动切新文件；保留最近 3 天 crash 日志，过期用
removeRecursively清理 - 上传不能只靠定时：必须叠加
uni.onAppHide（进后台时）、uni.onNetworkStatusChange（网络恢复时）、用户点击“反馈问题”按钮三重触发 - 上报前做轻量脱敏：过滤设备 ID 中的 IMEI、手机号字段；崩溃堆栈里若含敏感路径（如
/user/12345/token）需正则替换
真机验证和模拟测试缺一不可
很多团队上线后才发现崩溃日志为空，问题往往出在真机环境未验证。
- iOS 真机必须连 Xcode →
Devices and Simulators → View Device Logs，确认是否出现Termination Description: SPRINGBOARD类崩溃，这是原生层真正上报成功的信号 - Android 真机用
adb logcat | grep -i crash查看是否有 SDK 初始化日志（如Bugly init success） - 用插件提供的
crash.test()方法主动触发一次模拟崩溃，验证从写入本地文件、到上传服务器、再到后台可查的全链路是否通畅 - 特别注意 iOS 17+ 的隐私限制：如果用户关闭了「共享 iPhone 分析数据」，部分系统级崩溃信息会缺失，需在用户协议里明确告知并引导开启
最常被忽略的是崩溃日志和 JS 错误日志的上下文对齐——比如同一个用户同一分钟内既触发了原生崩溃，又上报了 uni.onError 的同步错误，但两个日志里 appVersion 或 sessionId 不一致，就无法归因。务必在 SDK 初始化和 JS 错误处理器里共用同一套设备标识生成逻辑，别让排查卡在第一步。
