iOS 与 macOS 崩溃报告解读
拖入测试者发来的 .ips 文件，或粘贴 Crashes 管理器里的报告。本页用大白话告诉你这是哪种崩溃（EXC_BAD_ACCESS、Swift 陷阱、未捕获异常、0x8badf00d 看门狗，以及 Apple 文档列出的所有终止代码），显示崩溃线程并标出来自你代码的帧，还会写好 atos 和 mdfind 命令，把地址还原成函数名和行号。全部在浏览器中运行。
iOS 15+ 和 macOS 12+ 的 JSON .ips、旧版文本 .crash，或 JetsamEvent 报告。崩溃报告可能含用户的设备信息：不会上传任何内容，读取都在本页完成。
在上方粘贴崩溃报告或拖入文件，即可解读。
字段名、异常类型和终止代码依据 Apple 关于崩溃报告的 Xcode 文档，核对于 2026-10-31。
工作原理
- •从 iOS 15 和 macOS 12 起，崩溃报告是 .ips 文件，含两个 JSON 对象：一行元数据（崩溃的 bug_type 是 309），然后是报告正文。地址以十进制存储：每一帧给出映像序号和偏移，本页把偏移加上该映像的加载地址，得到文本报告里那样的地址。
- •你的代码指 App 包里的任何二进制：主可执行文件以及包内的框架和扩展。这些帧会被标出，崩溃线程上的第一个就是该开始看的地方。
- •异常类型、子类型、信号和终止代码的解释依据 Apple 关于崩溃报告的 Xcode 文章，每条都附原文链接。报告里有的话，Swift 运行时自己的错误消息、Application Specific Information 以及未捕获异常的名称和原因都会单独列出。
- •对只有地址的你的代码帧，本页按二进制分组，写出带正确架构、加载地址和 dSYM 路径的 atos 命令，以及按构建 UUID 查找 dSYM 的 mdfind 命令。
- •也能读旧版文本 .crash 报告，包括未符号化的 Last Exception Backtrace 里括号中的地址列表。JSON 报告还会生成一份易读的文本版，方便复制到问题跟踪里。
- •Jetsam 事件报告（JetsamEvent_…）是内存报告，不是崩溃：本页显示系统结束了哪个进程、原因，以及占用最大的几个进程各用了多少内存。
它不做什么
- •不在浏览器里符号化：那需要你的 dSYM，而 dSYM 应该留在你的 Mac 上。复制 atos 命令到那里运行即可。上传构建时带了 dSYM 的话，TestFlight 和 App Store 的崩溃在 Xcode 的 Crashes 管理器里就已符号化。
- •不解析线程寄存器或 VM 区域图（报告本身写了的除外），也不读卡顿报告、spin 报告或 stackshot（其他 bug_type）。
- •解释针对的是崩溃类型，不是你的代码。KERN_INVALID_ADDRESS 可能有很多原因，真正的答案在你代码的那一帧和链接的 Apple 文章里。
常见问题
- 去哪里找 App 的崩溃报告？
- TestFlight 和 App Store 的构建：打开 Xcode → Window → Organizer → Crashes。测试设备：连上 Mac，从 Xcode 的 Devices and Simulators 窗口打开它的日志；或在设备上进入 设置 → 隐私与安全性 → 分析与改进 → 分析数据，分享以你 App 名称开头的文件。Mac：打开“控制台”→ 崩溃报告，或查看 ~/Library/Logs/DiagnosticReports。看门狗、代码签名、过热和 jetsam 报告不会出现在 Organizer 里，只在设备上。
- 怎么符号化崩溃报告？
- 需要崩溃那个构建的 dSYM，它的构建 UUID 必须与报告 Binary Images 里你二进制的 UUID 一致。用 mdfind "com_apple_xcode_dsym_uuids == <UUID>" 查找，或在 .xcarchive 的 dSYMs 文件夹里找，然后运行 atos -arch arm64 -o <App>.app.dSYM/Contents/Resources/DWARF/<App> -l <加载地址> -i <地址>。本页会根据报告写好这两条命令。
- 0x8badf00d 是什么意思？
- 这是看门狗的代码，读作 “ate bad food”：App 的主线程在启动或运行时没有及时响应，系统结束了它。主线程的调用栈显示它当时在做什么；把这些工作（同步网络、解析大文件、数据库迁移）移出主线程。
- EXC_BAD_ACCESS 和 EXC_BREAKPOINT 有什么区别？
- EXC_BAD_ACCESS（SIGSEGV 或 SIGBUS）是代码碰了不能用的内存：空指针或悬空指针、已释放内存、只读内存。EXC_BREAKPOINT（SIGTRAP）是代码故意停止进程，在 Swift 里就是运行时错误：强制解包 nil、as! 失败、数组越界、溢出、fatalError 或 precondition 失败。
- 为什么崩溃显示 SIGABRT？
- 进程调用了 abort()。通常是未捕获的 Objective-C 异常（例如 unrecognized selector 的 NSInvalidArgumentException、越界的 NSRangeException）。原因写在 Application Specific Information 里，Last Exception Backtrace 显示在哪里抛出；崩溃线程本身只显示 abort。
- 把用户的崩溃报告粘贴到这里安全吗？
- 报告不会离开你的浏览器：本页不会拿它发出任何网络请求。崩溃报告可能含设备和文件路径信息；如果要在别处分享易读版，请先检查一遍。