dSYM 文件是什么
dSYM（Debug Symbols）是 Xcode 编译时单独产出的调试符号文件。发给用户的二进制通常已经剥离符号：函数名、类型名、源文件路径、行号都不在 IPA 里，而在同一次构建对应的 dSYM 里。崩溃平台（Bugly、Firebase Crashlytics、Sentry）或本地的 atos，都靠这份文件把崩溃栈里的地址还原成「哪个函数」。没有匹配的 dSYM，线上崩溃就只剩一串地址。
在运行设置里打开「还原 dSYM 文件」
混淆会改写类型、字段和函数的名字。如果商店拿到的是混淆后的二进制，崩溃工具却还在用原始工程的 dSYM，栈会对不上；如果完全不还原，日志里看到的也是混淆后的符号，排查会非常困难。
在小蟹混淆工具的运行设置里打开「还原 dSYM 文件」。打开后，工具会按本次混淆的映射，把混淆后的符号写回一份可还原的 dSYM：商店和用户拿到的仍是混淆二进制，你自己留着这份还原后的 dSYM，就能在现有崩溃链路里把栈上的名字变回原始符号。每一次上传都应使用与 IPA 同一次运行产出的 dSYM，按构建号存放。不要把可还原的 dSYM 打进要提交的 IPA。
代码膨胀：崩溃栈能还原，行号没法正确定位
这一点需要特别说明。语言混淆可以做代码膨胀：会插入额外代码，函数体变长，指令地址相对原始源码发生偏移。打开还原 dSYM 之后，崩溃栈上的函数名、类型名仍能还原成原始符号，所以你能判断崩在哪个方法。但因为膨胀改变了指令布局，没法正确对应到原始源码的某一行。排查时应按函数和上下文定位，不要指望行号与 Xcode 里未混淆的源码逐行对齐。
栈仍然对不上时，先用 dwarfdump -u 核对二进制和 dSYM 的 UUID。Flutter 和 Unity 会带上额外的原生库，每个 image 都要还原，不能只处理主执行文件。见 常见问题 里关于崩溃日志的一条。操作手册：在线文档。