崩溃日志从哪来
手机App突然闪退，电脑软件无响应，这类问题背后通常都留有痕迹——崩溃日志。它像是系统或应用在“临终”前写下的日记，记录了出事时的环境、调用栈、内存状态等关键信息。拿到这份日志，就等于拿到了破案的线索。
在iOS设备上，崩溃日志可以通过iTunes（或Finder）同步后导出，路径藏得有点深，一般位于~/Library/Logs/CrashReporter。Android开发则多依赖ADB抓取logcat输出，尤其是应用崩溃那一刻的堆栈信息。桌面程序如使用Windows事件查看器，也能找到应用程序错误的详细记录。
看懂日志的第一行
打开一个崩溃日志，最先看到的往往是类似这样的内容：
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Triggered by Thread: 0这行信息非常关键。EXC_BAD_ACCESS通常意味着访问了已释放的内存，也就是野指针问题。而地址为0x0，极可能是空指针解引用。这类错误在Objective-C或C++项目中很常见，尤其是在对象释放后又被调用的情况下。
线程栈是核心线索
往下翻，你会看到各个线程的调用栈，主线程（Thread 0）尤其重要。它展示了程序崩溃前最后执行的函数路径。
Thread 0 name:
Thread 0 Crashed:
0 libobjc.A.dylib 0x00007fff201c8d0a objc_msgSend + 10
1 MyApp 0x000000010a2b345c -[ViewController viewDidLoad] + 124
2 UIKitCore 0x00007fff23b0f5ec -[UIViewController _performCoordinatedPresentOrDismiss:animated:] + 452从这段可以看出，崩溃发生在ViewController的viewDidLoad方法中，调用了某个已经释放的对象。顺着这个线索回代码里查，十有八九能发现哪里提前释放了对象，或者弱引用处理不当。
结合符号化还原真相
刚导出的日志通常是未符号化的，函数地址是一串数字。你需要用dSYM文件配合atos命令还原成可读的函数名。比如：
xcrun atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp 0x10a2b345c运行后会返回具体的类和方法名，让排查效率大幅提升。记得每次打包都要保留对应的dSYM，否则线上崩溃根本没法查。
模拟复现+打印辅助
光看日志有时不够。可以在Xcode或Android Studio里设置断点，模拟用户操作路径。加上NSLog或Log.d输出关键变量状态，往往能提前暴露问题。比如发现某个数组在特定操作后变成nil，再结合用户点击流程，就能锁定触发条件。
有时候崩溃只在低内存环境下出现。可以使用Xcode的Memory Warning模拟功能，或者在旧款设备上测试，更容易复现边缘情况。
第三方工具也能帮忙
上线后的应用，靠用户手动传日志不现实。集成像Firebase Crashlytics、Bugly这类监控工具，能自动收集并聚合崩溃数据。它们会按机型、系统版本、发生频率排序，一眼看出是不是集中在某个更新后爆发，帮助判断是否是新引入的问题。
比如某次发版后，发现80%的崩溃都来自Android 10的小米手机，那就要重点检查是否与权限申请或后台限制有关。这种统计视角，是单看一条日志难以获得的。