碰到生产环境崩溃、core 文件里满满一堆裸地址的时候，第一反应基本都是后悔当初没把调试信息带上。我自己在这个问题上吃过几次亏，后来固定成一套流程：发布之前，用 objcopy 把调试信息从最终二进制里剥离出来单独存档，线上程序保持瘦身干净的形态；等到线上真崩了，再用 GDB 挂上这份存档的调试信息，把崩溃行从地址堆里明确捞出来。这套方案折腾完，等于给自己留了一张随时能用的“现场还原卡”，适合所有做 Linux C/C++ 服务、嵌入式开发、桌面应用的团队和个人开发者参考。
先说清楚这套流程的价值：发布版继续保持小体积，不暴露源码结构，不拖慢部署；而排查崩溃时，GDB 依然能精确指出崩溃发生在哪个文件哪一行，甚至能看到局部变量和函数调用链。核心动作就是 objcopy 的几条命令，加上 GDB 加载符号文件的方式，都不复杂，但链条里每一步都有不少隐藏细节，任何一个环节理解偏了，最后都会卡在“版本对不上”“找不到符号”“core 没生成”这类问题上。下面我把完整思路、实操命令和踩过的坑一次性讲透。
1. 调试信息去哪了：先把拆分这件事想明白
1.1 一个真实项目的体积账
很多人对调试信息的体积没概念。拿我维护过的一个内部 HTTP 服务举例，源码量大概两三万行，编译时只加-g，最终二进制直接膨胀到 38MB；加-O2去掉调试信息后，二进制只有 6.2MB。换成一些底层库和 C++ 模板密集的项目，膨胀比例更夸张，三五倍只是起步，十倍也不稀奇。
这还没有算工具链和依赖库的调试符号。如果整个发布包都要带全量调试信息，镜像体积、容器拉取时间、升级带宽都会成倍增加。尤其现在不少场景是边缘设备或者跨机房拷贝，一个四十多兆的二进制和六兆的二进制，部署效率完全是两种体验。调试信息项目里最容易被砍掉，因为开发期不缺磁盘，发布期一算成本就想省。
但体积只是一个维度。真正麻烦的是，调试信息被剥掉之后，排障工具也跟着聋了：gdb打开 core，backtrace全是十六进制地址；addr2line也匹配不出文件名和行号。这时候再想定位线上崩溃，只能靠日志断点、二分猜测、甚至反汇编硬啃，效率低到让人想撞墙。
1.2 为什么发布版本不能直接带全量调试信息
除了体积，还有两个现实原因决定“全符号二进制”不适合直接发到生产环境。
第一个是安全与信息暴露。-g编译出来的二进制里，包含完整的源码路径、变量名、宏定义、结构体布局，甚至部分内联函数展开逻辑。把这种文件交到客户手上或者放在公网服务器上，等于给逆向分析开了一扇门。很多商业软件、私有协议实现、加密逻辑，都不愿意对外暴露这些细节。这时候直接 strip，整个二进制里的符号信息被清掉，能看到的只剩机器码和字符串常量，安全面一下就小了很多。
第二个原因更实际：带全量调试信息的二进制交付到生产，一旦出事，你根本不敢直接用那个现场文件做分析，因为你没法确认线上那台机器上的二进制和开发机里的完全一致。大家默认“既然发布了同一个包应该就是一样的”，但热更新、灰度发布、部分节点回退之后，版本早就乱了。反而是在构建机上单独提取出来的.debug文件，配合build-id，才能精确对应到某个构建产物。
1.3 正确思路：剥离、存档、需要时挂回
所以最关键的一步是想清楚：发布给生产的，是一个去掉符号和调试信息的瘦身程序；但构建机上仍然保留一份完整的调试信息档案。发生崩溃后，用 GDB 加载现场二进制、core 文件和这份档案，三者在同一台分析机上汇合，调试信息再“挂”回去。
这件事的日常开销是零。构建完成后跑一遍 objcopy，产物多出一个.debug文件，占的存储完全可控；发布时候如果不需要它，就放到内部对象存储或者构建产物归档区，不进生产目录。但一旦有崩溃，这份.debug文件的价值立刻体现出来，GDB 可以顺着二进制里的关联信息自动找到它，或者你手动用symbol-file加载，崩溃行、参数、变量一目了然。
2. objcopy 分离调试信息的三种姿势与完整脚本
2.1 三个核心选项，一次讲清
objcopy是 binutils 里专门处理 ELF 文件拷贝和改写段的工具。做这件事主要用三个选项，它们的差别很多人一开始分不清。
--strip-debug：只移除调试相关段（DWARF 信息、.debug_*段），但保留.symtab和.strtab。用nm看，函数名还在，符号表还在，只是没有行号映射。--strip-all：移除所有符号、重定位信息、调试段。处理完之后nm基本是空的，程序体积最干净，但也意味着崩溃现场只剩地址。--only-keep-debug：反过来，把调试相关的段提取出来，输出成一个单独的.debug文件。这个文件不是可执行程序，不能直接跑，但里面保留着完整的 DWARF 调试信息，专门给 GDB 当符号源用。
实际操作中，发布版本绝大多数应该用--strip-all，而不是--strip-debug。原因很简单：既然要瘦身和防信息泄露，留下.symtab没有意义，还凭空多出一个可被扫描的符号入口。真正要保留的完整调试信息，全部放在.debug文件里，发布程序不留。
这三个选项之外还有一个容易忽视的：--add-gnu-debuglink。它会在二进制里写入一个.gnu_debuglink段，记录调试文件的名字和 CRC 校验值。这样 GDB 后续打开这个被剥过的二进制时，会主动在当前目录或指定调试目录里寻找对应的.debug文件，不需要每次手动加载。
2.2 可直接抄的 objcopy 三步流程
我这边通常用一套三段式脚本处理：
# 假设 make 已经产出了一个带调试信息的完整二进制 build/bin/app.full APP=build/bin/app # 第一步：只保留调试信息 objcopy --only-keep-debug "$APP.full" "$APP.debug" # 第二步：去掉发布版所有符号 cp "$APP.full" "$APP" objcopy --strip-all "$APP" # 第三步：在发布版里写入 debuglink，指向存档的调试文件 objcopy --add-gnu-debuglink="$APP.debug" "$APP"三步顺序不能乱。如果先 strip 再提取调试信息，.debug文件里就是空的；如果 debuglink 加在 strip 之前，万一 strip 时把整个段改写掉，关联关系就丢了。稳妥做法就是把源文件先保留一份.full副本，再操作发布版。
这里有个很多人踩过的细节：objcopy --only-keep-debug提取出来的.debug文件，虽然体积可能还有十几兆，但它只包含调试段和少量符号信息，没有代码段、数据段，不适合直接在线上运行，这就是它适合归档的原因。你可以只保留.debug而丢掉.full，因为.debug已经覆盖了 GDB 需要的全部信息。
如果你希望.debug文件体积更小，可以顺手做一次压缩：
objcopy --compress-debug-sections=zlib-gnu "$APP.debug"GDB 读取时会自动解压。新版 GDB 同时支持zlib-gnu和zlib-gabi，GDB 13.2 上我用下来都很稳，历史老版本可能对zlib-gabi兼容性略差，保守起见用zlib-gnu更保险。压缩率通常能到一半以上，适合长期归档。
2.3 验证拆分结果：不是 strip 完就完事
命令跑完不要直接收工，验证环节必须做。我一般用下面几条命令快速检查：
# 查看发布版是否被剥干净 file "$APP" nm "$APP" | wc -l # 查看调试文件里是否保留着完整调试段 file "$APP.debug" readelf -S "$APP.debug" | grep debug # 查看 debuglink 是否写入成功 readelf -x .gnu_debuglink "$APP" | head -20正常情况下，file输出里会有stripped字样，nm输出行数接近 0；.debug文件里能看到一长串.debug_info、.debug_line、.debug_abbrev之类的段；readelf -x .gnu_debuglink的十六进制内容里，除了文件名，还会有一行 CRC 值。这个 CRC 就是 GDB 用来验证调试文件和二进制是否匹配的依据之一。
除了以上检查，我建议顺手把build-id也记下来：
readelf -n "$APP" | grep "Build ID"每个 ELF 文件在链接时通常都会生成一个唯一build-id，它比文件名+CRC 更能精确标识“这个二进制是哪次构建出来的”。这个值后面在 GDB 加载时作为最后一道验证锁，非常重要。
2.4 压缩调试段与目录归档策略
调试文件提取出来之后，怎么组织目录可以按团队习惯来，我推荐一种基于build-id的结构。GDB 除了支持.gnu_debuglink按名字搜索，还支持在全局调试目录里按build-id定位。假设刚才读取到的build-id是abc123...，存档时这样放：
mkdir -p /srv/debugstore/.build-id/ab cp "$APP.debug" /srv/debugstore/.build-id/ab/c123....debugbuild-id前两位作为子目录名，剩余部分作为文件名，末尾加上.debug。这样 GDB 只需要设置一句set debug-file-directory /srv/debugstore，以后打开那个版本的发布二进制时，会自动顺着.note.gnu.build-id找到对应的.debug文件，连 debuglink 名称都不用操心。这套方式非常适合 CI 里多版本存档。
3. 从 core dump 到崩溃行：GDB 实战全流程
3.1 先保证崩溃现场能被记录下来
分离调试信息只是前半段，后半段是崩溃现场采集。最核心的前提是：崩溃时操作系统真的写下了 core 文件。很多生产环境默认不写 core，配置不对的话，前面所有准备工作都白搭。
先检查当前 shell 的限制：
ulimit -c如果是 0，core 不会生成，执行ulimit -c unlimited放开限制。再检查系统全局配置：
cat /proc/sys/kernel/core_pattern这个文件决定了 core 文件的命名和位置。很多桌面版 Linux 发行版默认把它交给了apport或者systemd-coredump接管，结果你以为生成了 core，实际却不知道被压缩到了哪里。Ubuntu 24.04 这类新系统，我记得默认是走 systemd-coredump 的，查看方式不是直接找core.*，而是：
coredumpctl list coredumpctl info <PID>如果 systemd-coredump 确实接管了，core 文件默认会在/var/lib/systemd/coredump/下，而且带 zstd 压缩，直接用 GDB 读会有问题。推荐把它导出成普通 core 再分析：
coredumpctl dump <PID> -o ./core.dump对生产服务，我更建议直接修改 core_pattern，指定一个固定目录和文件名模板。比如写进/etc/sysctl.d/99-core.conf：
kernel.core_pattern=/var/crashcores/core.%e.%p.%t然后用sysctl -p生效。这样每次崩溃都会生成一个带程序名、进程号、时间戳的 core 文件，后面定位时信息全面，也方便脚本批量处理。
容器环境要多留一个心眼：即使宿主机允许 core dump，容器里ulimit -c可能被默认限制，/proc/sys/kernel/core_pattern也可能指向宿主机的管道命令，导致容器内没有落盘。这种情况优先在容器启动参数里加--ulimit core=-1，并把 core 目录挂载到宿主机上。还有一个更保险的做法：进程还活着的时候，用 GDB 的gcore直接拍现场，这个我在后面的心得里再展开。
3.2 GDB 加载 core 与调试文件的正确姿势
假设已经拿到了发布二进制app、存档的调试文件app.debug和刚生成的 core。加载时我习惯这样操作：
gdb ./app /var/crashcores/core.app.12345进入 GDB 后先设置调试目录，再手动确认符号加载：
(gdb) set debug-file-directory /srv/debugstore (gdb) symbol-file /srv/debugstore/.../app.debugdebug-file-directory告诉 GDB 去哪里找.debug文件；symbol-file是手动指定具体文件。如果刚才用--add-gnu-debuglink建立了关联，且.debug文件就在与 app 相同的目录，GDB 打开时会自动加载，不需要这些手动操作。但公网服务器上一般不会放.debug文件，所以set debug-file-directory和内网存档配合才是标准姿势。
如果 GDB 正确加载了调试符号，启动时会显示类似如此的信息：
Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000555555554a12 in handle_request (req=0x7fffffffe2b0) at server.c:87server.c:87就是崩溃行。这一步成功了，后面所有定位工作都会轻松很多。
这里提醒一句，GDB 加载 core 文件时，真正需要的是“产生这个 core 时的那个版本二进制”。如果你手头没有当时的二进制，只有.debug文件，加载会失败或者给出很奇怪的地址。二进制缺失时，GDB 无法知道内存映射和段布局，这也再次说明发布版本身也需要在每个版本里归档一份。
3.3 定位崩溃行的命令组合与输出解读
调试信息挂上之后，我最常用的命令组合是这样一套：
bt首选命令。输出完整调用栈，从崩溃点逐层往上到 main：
#0 0x0000555555554a12 in handle_request (req=0x7fffffffe2b0) at server.c:87 #1 0x0000555555554b50 in process_conn (conn=0x55555556a200) at server.c:143 #2 0x0000555555554c88 in main (argc=1, argv=0x7fffffffe3d8) at server.c:189栈顶#0是崩溃点，但千万别只盯着栈顶。真正导致崩溃的往往不是#0的那个函数，而是它的调用者传入了错误参数。继续执行：
bt full把每个栈帧的局部变量、参数一起打出来。这个对排查“谁传了脏数据”极有用。看到req指向一个看似很合理的地址，但resp->body已经越界时，问题就浮出水面了。
接下来看崩溃点的现场：
frame 0 info registersframe 0切到最顶层栈帧，info registers看寄存器值。特别是$rip（指令指针）和与地址相关的$rdi、$rsi，往往在崩溃瞬间还保留着触发崩溃的地址。再配合list看崩溃行附近的源码：
list如果怀疑反汇编层面的问题，可以用：
x/10i $pc把当前指令地址附近的机器码反汇编出来。这套组合下来，绝大部分段错误、非法指令都能定位到函数和行。
多线程程序还有一个必做动作：
thread apply all bt把所有线程的栈一次性打出来。后面讲坑的时候我再重点说，这里先记住这个命令。
3.4 版本对不上的判定：build-id 是第一道锁
生产环境最容易遇到的问题：core 文件明明有了，GDB 也打开了，但显示的地址完全对不上，或者bt出来第一行就是#0 0x0000000000000000。大概率是现场二进制和 core 不匹配，或者你手里的.debug文件和现场二进制不是同一次构建的产物。
GDB 本身会给出一定的警告，比如“exec file is newer than core file”。但更可靠的判定手段是build-id。构建时我们已经记下了发布版的build-id，在分析机上再次执行：
readelf -n ./app | grep "Build ID"和存档记录里的值对比。如果两者一致，这份 core 可以放心分析；如果不一致，宁可回去找正确的发布包，也不能硬凑。有人会觉得“反正只差一个构建，symbol 差不多能用”，我劝你千万别赌这个。优化开关、编译器版本、宏定义任何一个变化，都可能让栈帧完全错位，分析出来的结果比瞎猜好不了多少。
.debug文件本身也可以校验：
readelf -n app.debug | grep "Build ID"如果二进制和.debug文件的build-id一致，说明这份调试信息对应上了；如果不一致，GDB 加载时往往也会拒绝或者报错。把build-id作为每个构建产物的唯一标识养成习惯，后面能省事很多。
3.5 顺带一提：VSCode 可视化加载 core
命令行 GDB 用熟了之后，日常调试我偶尔也用 VSCode 看一下调用栈，主要因为图形界面里双栏变量监视和源码高亮确实直观。方法是编辑.vscode/launch.json：
{ "version": "0.2.0", "configurations": [ { "name": "Analyze Crash", "type": "cppdbg", "request": "launch", "program": "/path/to/app", "coreDumpPath": "/path/to/core.dump", "additionalSolibSearchPath": "/srv/debugstore" } ] }把program指向发布版二进制，coreDumpPath指向 core 文件，additionalSolibSearchPath指到内网调试目录。启动后 VSCode 会像调试普通程序一样高亮崩溃行，左侧调用栈直接点切帧。分析线上事故时，这个效率比纯命令行高，特别适合不熟悉 GDB 的同事参与排障。
要注意这依赖本机装了 C/C++ 扩展以及 GDB，且当前环境能访问到 debug 存储。VSCode 对coreDumpPath的支持各版本略有差异，遇到不生效时可以退回命令行方式，但多一种工具总是好事。
4. 崩溃排查中那些防不胜防的坑
4.1 编译参数救不了流程缺失
第一个坑不是技术坑，是流程坑。有些项目编译时压根没有加-g，发布前也没有做only-keep-debug这步，等到崩溃发生，才想起来找调试信息，结果什么都没有。这种情况下神仙来了也难办，唯一能做的只剩用objdump看反汇编，或者祈祷日志里打了足够多的上下文。
我见过一个团队为了省 CI 时间，把-g从编译参数里去掉了，只保留-O2，美其名曰“发布版不调试”。结果线上一个偶发崩溃查了三天，最后只能靠加日志重发版本。加-g并不影响优化，-g -O2同时开启，调试信息照常生成，除了文件大一点没有任何运行时开销。省-g是最愚蠢的优化。
流程上要保证：每个发布版本都带着完整调试信息进入构建系统；strip 必须在调试信息提取完成之后进行；发布产物和.debug归档必须保持同样的build-id。这三条缺一不可。最好把这些写进 CI 脚本，而不是靠开发者手动执行。
4.2 -g 和 -O2 并存时，行号会“漂”
就算加了-g，-O2优化下 GDB 显示的行号也可能不完全符合直觉。编译器会做指令重排、函数内联、常量折叠，有些代码块可能根本没有对应的机器码，有些看似在第 90 行的strlen调用，实际崩溃地址指向的是第 87 行附近的指令。
这个问题我没法完全消除，但有三个缓解经验。第一，发布版建议保留-fno-omit-frame-pointer，编译器不做栈帧省略，backtrace 质量会明显提升；第二，分析时不要把崩溃行当成铁证，把它当线索，结合调用链和寄存器内容判断真实原因；第三，遇到特别诡异的崩溃，可以刻意编一个-O0 -g的复现版，但注意优化版和未优化版行为可能不同，不要轻易用它来否定线上 core 分析结论。
还有一点，GDB 在优化代码里显示变量值经常显示<optimized out>，这是正常的。此时看寄存器里的地址比看变量名更靠谱。
4.3 core_pattern 被接管，core 文件到底去哪了
前面提到过 Ubuntu 这类系统默认会把 core_pattern 指向systemd-coredump，这里单独拎出来强调，因为太多人在这个坑里浪费过时间。你以为程序崩了系统会吐一个core，结果当前目录什么都没有，日志里也看不到任何痕迹。
处理办法分两步。第一步先查cat /proc/sys/kernel/core_pattern，如果是管道命令（以|开头），说明 core 被其他进程接管了。第二步针对不同接管者处理：systemd-coredump用coredumpctl list查，apport则可能把 core 转成了一个.dmp或直接丢弃。生产环境建议直接改 core_pattern 到自己的目录，像我在 3.1 节里写的那样，别依赖发行版默认行为。
改完 core_pattern 之后最好亲自验证一次。用一个已知会崩溃的小程序触发一次崩溃，看指定目录里是否生成了正确的 core 文件。这一步验证成本极低，但能避免真正出事那天才发现配置没生效。
4.4 找不到调试符号，手动挂回来
GDB 打开后提示“no debugging symbols found”的情况也很常见。原因无非这几种：.debug文件路径不对、二进制和.debug文件build-id对不上、debug-file-directory设置错误。
按顺序排查：先确认.debug文件确实存在；再比较两个文件的build-id；最后检查 GDB 里show debug-file-directory的路径设置。如果以上都没问题，手动执行一次symbol-file /path/to/app.debug，通常就能把符号挂回来。
还有一种情况是 GDB 找到了调试符号，但显示源码时提示找不到源文件。这是因为构建机上源码绝对路径和当前分析机不一致。用dir添加源码目录，或者用set substitute-path做路径映射：
(gdb) set substitute-path /build/ci/myapp /home/me/src/myapp这个功能在 CI 构建、异地分析场景里非常实用，不然list只能看见行号却看不到代码内容，体验很差。
4.5 多线程崩溃别忘了把所有线程栈都拉出来
最后这个坑非常隐蔽。GDB 打开 core 之后默认停在触发信号的线程上，你会觉得“崩溃点不是已经定位到了吗”，于是顺着这个线程一路分析下去。但真正把程序搞崩的那个线程，往往不是接收信号的线程。
举例来说，一个线程正在用free()释放一块被另一个线程正在写的内存，崩溃表面发生在free()内部，栈顶自然在free和它的调用者；但写坏内存的那个线程此刻早就不在这个栈上了。如果只分析崩溃线程，你只能看到“释放了非法指针”，却看不到谁破坏了它。
正确姿势是一上来就执行thread apply all bt，把所有线程的调用栈保存下来，对照业务日志和共享数据结构，才能还原完整的事故现场。这个动作应该成为 crash 分析的固定第一步，不是可选项。
5. 长期实践下来值得沉淀的几点
5.1 在 CI 里固化“可追溯档案”
这套流程要真正长期有效，就不能只靠手工执行。我建议在 CI 里固化一整套“可追溯档案”生成逻辑，每个构建版本自动输出三样东西：发布用瘦身二进制、GDB 用调试文件、版本记录文件。
一个简单的脚本形状如下：
#!/bin/bash set -euo pipefail APP=build/bin/app VERSION=$(git rev-parse --short HEAD) OUT=release/$VERSION mkdir -p "$OUT/debug/.build-id" cp "$APP" "$OUT/app.full" objcopy --only-keep-debug "$OUT/app.full" "$OUT/app.debug" objcopy --strip-all "$OUT/app.full" "$OUT/app" objcopy --add-gnu-debuglink="$OUT/app.debug" "$OUT/app" BUILD_ID=$(readelf -n "$OUT/app" | sed -n 's/.*Build ID: \([0-9a-f]*\)/\1/p') mkdir -p "$OUT/debug/.build-id/${BUILD_ID:0:2}" cp "$OUT/app.debug" "$OUT/debug/.build-id/${BUILD_ID:0:2}/${BUILD_ID:2}.debug" echo "VERSION=$VERSION" > "$OUT/version.txt" echo "BUILD_ID=$BUILD_ID" >> "$OUT/version.txt"发布时只把$OUT/app推到生产，内部存档则完整保留app.full、app.debug、version.txt。以后不管隔了多久，拿到现场二进制就能靠BUILD_ID精确找到对应调试文件。把这个脚本接到 CI 的 release job 里，之后每次事故分析都等于有了自动化保险。
5.2 进程没崩但疑似卡死：用 gcore 抓现场
core dump 依赖进程真的崩溃退出了。另一种常见情况是进程还活着，但明显卡死，CPU 飙高、请求不返回、或者线程任务卡在某处。这时候没有 core 文件可用，也不是崩溃信号，我通常直接用 GDB 挂上去抓取现场：
gdb -p <PID> (gdb) gcore /var/crashcores/core.live.xxx (gdb) detachgcore命令会在进程还活着的时候把完整内存映射、寄存器、线程栈全部导出来。之后用相同版本的.debug文件正常分析即可。这个手段对“看起来像死循环”“疑似死锁”这类问题的定位非常有用。注意在生产进程上操作时动作要快，避免长时间中断业务。如果进程的dumpable属性被设置成了 0，可能无法 attach，需要先处理权限。
5.3 没有 GDB 时，addr2line 也能救急
很多生产环境不允许安装完整调试工具链，但通常会有 addr2line 或者可以用 busybox 里的替代命令。崩溃日志有时来不及保存 core，只留下一行RIP: 0x7f1234567890这样的地址。这时候 addr2line 能做个快速换算。
先用/proc/<pid>/maps或者 core 文件找到对应代码段的加载基址。假设崩溃地址是0x7f1234567890，某共享库的加载基址是0x7f1234000000，则文件内偏移是0x567890。然后执行：
addr2line -e libfoo.so.debug -f -C 0x567890就能看到函数名和源码行号。对 PIE 可执行文件，原理一样，减掉映射基址再传给 addr2line。这个方式不如 GDB 直观，但在救援场景能多一条命。更完整的信息还是建议配合 core 文件。
5.4 源码目录别名问题：set substitute-path 实战
最后说一个工作流细节。.debug文件里的源码路径是构建时的绝对路径，比如/build/ci/myapp/server.c。而你本地代码在/home/me/src/myapp，直接list会提示找不到文件。GDB 的路径替换规则可以解决：
(gdb) set substitute-path /build/ci/myapp /home/me/src/myapp (gdb) list这句命令在 CI 构建、异地归档场景里几乎必用。建议把路径映射写进每个人的~/.gdbinit或者分析脚本开头，省得每次打开 GDB 都要手工设置。还有一个小技巧，如果分析机上源码目录已经移动过多次，可以连续设置多条 substitute-path 规则，GDB 会按顺序尝试匹配。
我个人这几年的体会是：剥离调试信息不是销毁调试能力，而是把调试信息单独养起来，平时看不到，关键时候能救命。核心动作就两条：一是在构建机上用 objcopy 提取.debug文件并建立 debuglink 或 build-id 目录，二是发版时把 build-id 和代码版本记录下来。多做这三五分钟，后面排查崩溃能省下好几个小时。发布前，值得顺手把那三条 objcopy 命令固化到 CI 流程里，别等线上告警了才想起来找调试信息。
