函数栈帧从创建到销毁：局部变量、返回地址与栈溢出的底层原理

搞C/C++的朋友，早晚会在某个深夜面对这样一个灵魂拷问：局部变量到底存在哪里？为什么函数一返回，里面的变量就“没了”？如果你只用“栈上分配、栈上释放”这种答案应付过去，那离真正理解计算机运行机制还差着一大截。

我当年第一次在gdb里用info registers看到rsp和rbp跳来跳去的时候，才真正明白什么叫“函数栈帧的创建和销毁”。这东西不是考试应付一下就行的冷门考点，它是理解局部变量生命周期、栈溢出崩溃、调试器backtrace工作原理、甚至安全攻防的基础。这篇就把函数栈帧这件事从头到尾拆开讲透，用实际反汇编和调试记录说话，看完你再去读那些讲缓冲区溢出的文章，会轻松非常多。

1. 栈帧到底是个什么东西

1.1 先搞清楚“栈”和“堆”的区别

很多初学者分不清“栈”和“堆”，典型表现就是背概念：“局部变量在栈上，动态分配在堆上”。概念没错，但没建立起画面感。

你想象一块连续的内存，从高地址向低地址增长，这块区域就是程序运行时的调用栈（call stack）。每次调用一个函数，系统就在当前栈顶划分出一块区域，专门给这个函数用，存它的局部变量、参数、返回地址等。这块区域就是“函数栈帧”（stack frame）。

栈和堆最大的区别在于生命周期和分配方式：

• 栈的分配和释放是自动的，函数调用时“划地”，函数返回时“回收”，不需要你手动管理。
• 栈是从高地址往低地址长，堆是从低地址往高地址长，两个方向正好相反，中间空着的地方供两者自由生长。
• 栈空间有限，一般几MB级别，堆空间大得多，所以大数组、递归过深往往会栈溢出，而malloc大块内存通常不会立刻崩。

你不需要关心操作系统具体怎么管理物理页，只要记住一点：函数栈帧就是函数在栈上的“私人办公区”，函数一旦返回，这块办公区就“作废”了，里面的数据逻辑上不存在了，但物理上内存里的值还在，只是没人管了。这也是为什么返回局部变量的指针是危险的——指针指向的地址还在，但内容随时可能被下一个函数调用覆盖。

1.2 关键寄存器：rsp、rbp和指令指针

在x86-64体系下，有三个寄存器跟栈帧息息相关：

• rsp（栈指针寄存器）：始终指向当前栈顶，也就是“下一个可用位置”。所有栈操作（push、pop、call、ret）都会改动它。
• rbp（基址指针寄存器，也叫帧指针）：指向当前函数栈帧的底部，用于方便地访问局部变量和参数。
• rip（指令指针寄存器）：指向当前正在执行的指令地址，函数调用和返回本质上是改变它的值。

32位时代对应的是esp和ebp，原理完全一样，只是寄存器宽度不同。网上很多老的博客讲的是32位的ebp，你在64位机器上看反汇编，看到的可能是rbp，其他逻辑差不多。

这里有个容易绕晕的点：栈向下增长，所以“栈底”其实是高地址，“栈顶”是低地址。push操作会让rsp减小，pop操作会让rsp增大。画栈图的时候，建议把地址从下往上递增画——也就是栈底在高地址在上方，栈顶在低地址在下方，看反汇编代码时对着这个图就不会乱。

注意：现代编译器在开优化的情况下经常会省略rbp，直接用rsp加偏移来访问局部变量，这种叫帧指针省略（-fomit-frame-pointer）。但不影响理解原理，反而更能看出栈帧的本质——它只是一个“约定”，不是硬件强制的。后面我会专门讲这个。

2. 函数调用之前，调用者都干了些什么

2.1 参数传递：寄存器优先，栈上兜底

写一个最简单的函数：

c复制int add(int a, int b)
{
    int c = a + b;
    return c;
}

然后gcc -S生成汇编（不开优化），你会看到主调方调用add之前做了这些事：

assembly复制movl    $3, %esi
movl    $2, %edi
call    add

就三句。edi和esi是x86-64 SysV调用约定里传递前两个整数参数的寄存器。如果你的函数参数超过6个（整数/指针类型），第7个及以后的参数才会压到栈上传递。

这块有个值得展开的细节：

• 参数从右往左压栈是cdecl调用约定的习惯，但是x86-64下多数参数走寄存器，所以压栈顺序只在参数多的时候才体现出来。
• 浮点参数走xmm0到xmm7，和整数参数分开。
• Windows x64调用约定和System V不一样，参数传递用的寄存器也不同，跨平台写汇编或者逆向分析时得先搞清楚目标平台的约定，否则看反汇编会一头雾水。

call add这一条指令其实是两步操作的合体：

1. 把返回地址（也就是call指令的下一条指令的地址）压入栈中。
2. 把rip改为add函数的入口地址，程序跳转过去执行。

所以进入add函数那一刻，栈顶（rsp指向的位置）压着的就是返回地址，占8个字节（64位下）。

2.2 call指令做了哪些不显眼的事

很多人不理解为什么call和ret能自动配对。其实call的本质就是“先存好回来的路，再跳走”，ret的本质就是“按着存好的路走回来”。

具体流程：

code复制call add 等价于:
    sub rsp, 8            ; 栈顶向下挪8字节，腾位置
    mov [rsp], 返回地址   ; 把返回地址写入栈顶
    jmp add               ; 跳转到add函数入口

返回地址具体是多少？就是call指令的下一条指令地址。假设上面三句汇编里call add后面还有一条mov指令，那返回地址就是那条mov指令的地址。函数执行完后回到这里继续往下跑，整个程序的执行流才不会断。

理解了这一点，你再回头看递归调用就明白多了：每次递归调用都会在栈上压入新的返回地址和新的栈帧，嵌套多少层，栈上就堆多少层“返回记录”。如果递归没有终止条件，栈空间被耗尽，就会触发栈溢出，程序崩掉。

2.3 一个容易忽略的约定：栈对齐

SysV ABI有一个硬性要求：在call指令执行之前，栈顶rsp要保证16字节对齐。为什么？因为有些指令集要求内存操作数对齐，尤其是一些SIMD指令（比如movaps），遇到未对齐的地址会直接抛出段错误。

这个细节很折磨人，因为正常写代码根本感觉不到它的存在，但一旦你写内联汇编或者手工构造函数调用，没对齐栈，程序就会莫名其妙在某个库函数里崩溃。我遇到过最经典的一次是在自己实现的HTTP解析器里手动调用一个回调函数，debug了一下午，最后发现是栈对齐问题。

16字节对齐推演起来是这样：

• 进入函数前，rsp是16字节对齐的。
• call压入8字节返回地址，所以进入函数时rsp % 16 == 8。
• 如果函数里有push rbp，压入8字节，此时rsp % 16 == 0，重新对齐。
• 之后编译器分配局部变量空间时，sub rsp, N里的N也会设计成让rsp保持16字节对齐。

所以你在反汇编里看到sub rsp, 40、sub rsp, 24这类“不是8的整数倍”的数，别奇怪，是编译器在对齐。

3. 被调函数的开场白：栈帧的创建

3.1 标准序言：push rbp和mov rbp, rsp

进入函数执行的第一件事，是保存上一个函数的栈帧底地址，然后建立自己的栈帧底。这就是传说中的“函数序言”（prologue）。

对于开头的add函数，不开优化的反汇编长这样：

assembly复制add:
    push    rbp              ; 保存上一个函数的rbp（会压入栈中）
    mov     rbp, rsp        ; 让rbp指向当前栈顶（老rsp位置）
    sub     rsp, 16         ; 给局部变量腾空间（16字节，供c和可能的临时值用）
    mov     DWORD PTR [rbp-4], edi   ; 把参数a存到局部变量区
    mov     DWORD PTR [rbp-8], esi   ; 把参数b存到局部变量区
    mov     eax, DWORD PTR [rbp-4]
    add     eax, DWORD PTR [rbp-8]
    mov     DWORD PTR [rbp-12], eax  ; c = a + b，c存在[rbp-12]
    mov     eax, DWORD PTR [rbp-12]  ; 返回值放在eax中
    leave                        ; 函数收尾
    ret

开盘两句push rbp; mov rbp, rsp是经典组合，含义是：

1. push rbp：把调用者的rbp存到栈上。因为每个函数都有自己的栈帧底，当前函数结束时得恢复调用者的rbp，这样调用者才能继续正确定位自己的局部变量。
2. mov rbp, rsp：此时rsp指向刚压栈的旧rbp，让rbp指向这个位置，等于是给当前栈帧画了一个“底”。

完成这两步后，当前栈帧的布局开始成型：

code复制高地址
+------------------+
|   调用者栈帧      |
+------------------+
| 返回地址 (8字节)  |  <- 进入函数时rsp指向这里
+------------------+
| 调用者的rbp (8字节)|  <- push rbp后rsp指向这里，即rbp
+------------------+
| 局部变量区        |  <- rsp指向这里（低地址）
+------------------+
低地址

画这个图用了整整几分钟，但对理解后面所有内容非常关键：返回地址和旧rbp是紧密相邻的，rbp指向旧rbp的位置，返回地址在rbp+8。 这两个8字节的位置是缓冲区溢出攻击的核心目标，后面细说。

3.2 局部变量怎么在栈上分配

sub rsp, 16这条指令是给局部变量腾空间。为什么是16字节？因为c只是一个int，4字节就够了，但编译器为了对齐和预留临时空间，往往多分配一些。

局部变量在栈上的地址是通过rbp加负偏移来访问的：

• [rbp-4]对应a
• [rbp-8]对应b
• [rbp-12]对应c

跟直觉有点出入：参数明明是edi和esi两个寄存器传进来的，函数还是把它们先存到栈上，再读回寄存器运算。这是不开优化的典型表现，编译器为了调试方便，会尽量让每个变量都有确定的栈地址。

开了-O2之后，同样的函数会被优化成：

assembly复制add:
    lea    eax, [rdi+rsi]   ; 直接算完放eax
    ret

两条指令搞定。局部变量c根本没在栈上出现，a和b也没存栈。这就是优化把栈帧“压扁”了的经典例子。不是说栈帧不重要了，而是编译器优化掉了不必要的栈使用。

如果你写的是递归函数或者变量被取地址（比如int *p = &c），编译器就不能随便消除栈上的位置，因为指针必须指向真实的内存地址。

3.3 为什么局部变量是“垃圾值”

不管多简单的函数，只要你不在声明时初始化局部变量，打印出来就会是乱七八糟的值。原因在栈帧的创建方式里已经注定了：sub rsp, 16只是把栈指针往下挪了，并没有把这块内存清零。上面残留的是上一个函数使用过的数据。

所以“局部变量默认是垃圾值”这件事不是语言规定的，而是栈的实现方式决定的。堆上的malloc同样不清零，只有calloc会主动清零。C语言追求的是效率，清零是额外开销，能省就省。

这也是为什么很多安全编码规范强调要初始化变量：如果忘记初始化，程序可能读到残留的数据，在某些场景下甚至会泄露敏感信息（历史上真出过内核信息泄露漏洞）。

4. 函数执行中的栈帧：访问参数与局部变量

4.1 通过rbp偏移定位数据

函数执行期间，所有局部变量、函数参数的访问都是通过rbp加偏移完成的。这就是为什么要费劲保存旧rbp、建一个新的rbp——它就像栈帧的“锚点”，有了它，不管栈顶（rsp）怎么变，你都能稳定地找到自己的变量。

比如，如果函数里还有一个循环调用了别的函数，执行到一半的时候rsp会上下浮动（子函数压栈），但rbp始终不变，[rbp-4]依然准确指向当前函数的局部变量。这就是“帧指针”存在的意义。

在不开优化的情况下，gdb里查看变量地址时经常能看到0x7fffffffe...这种高地址，然后局部变量在某个rbp偏移处。用gdb命令：

bash复制info registers rbp rsp
x/10gx $rbp-16

就能直观看到栈上的数据布局。

4.2 数组和结构体的栈上布局

数组和结构体的局部变量也分配在栈上，但布局略有讲究。比如：

c复制void foo(void)
{
    char buf[8];
    long x = 0;
}

反汇编大概长这样（不开优化）：

assembly复制foo:
    push    rbp
    mov     rbp, rsp
    sub     rsp, 32          ; 分配48或其他值，具体看编译器和对齐
    ...

注意编译器实际分配的字节数可能远大于数组的8字节，因为需要对齐，还可能要留防越界检测（比如开启-fstack-protector后会在变量和rbp之间插入一个随机值，叫canary，函数返回前检查它有没有被改动，用来检测缓冲区溢出）。

数组元素从低地址向高地址排列，即buf[0]在低地址，buf[7]在高地址。如果对buf越界写，比如写了buf[8]到buf[15]，就直接覆写了距离buf最近的栈上数据。具体覆写到啥，要看buf和rbp、返回地址的相对位置。这就是缓冲区溢出漏洞的根源——往数组里多写几个字节，可能改写掉栈上的关键数据。

我实测过一个示例，char buf[8]，坐标关系大概是这样（不开启canary时）：

code复制rbp+8  返回地址
rbp    旧rbp
rbp-?  ...可能的填充...
rbp-8  buf[0]~buf[7]（buf地址一般是rbp-8）

也就是说越界写16字节就可能覆盖到rbp+8上的返回地址。攻击者只要精心构造这16字节的内容，就能让函数返回时跳转到攻击者指定的地址。这就是经典的栈溢出利用思路。

4.3 可变长数组（VLA）和alloca的特殊情况

C99引入了可变长数组（Variable Length Array），比如：

c复制void foo(int n)
{
    char buf[n];
}

这种数组的长度在运行时才知道，所以编译器不能在编译期确定sub rsp, 常量，而是要在运行时计算后，动态地把rsp往下挪n字节。这种情况下局部变量的地址访问会变得更复杂，有的编译器会用rsp加偏移而不是rbp加偏移来访问。

alloca函数也类似，直接在当前栈帧上动态分配内存，分配完记得编译器会去调整rsp。用alloca要格外小心，分配太多直接栈溢出崩溃，而且因为它在函数返回前不会释放，放在循环里等于无限吃栈空间。

5. 函数返回：栈帧销毁与栈恢复

5.1 返回值怎么带回给调用者

函数返回前，第一步是把返回值放到约定好的寄存器里：

• 整数和指针返回值放rax
• 浮点返回值放xmm0
• 结构体比较大的时候，调用者会预先分配一块内存，把地址作为隐藏参数传进来，函数把返回值写进那块内存

所以add函数里最后一句mov eax, DWORD PTR [rbp-12]就是给rax赋返回值。函数执行的每个分支，最后都要确保把正确的值放进rax，否则返回给调用者就是错的。

5.2 leave和ret的分工

函数收尾的经典组合是：

assembly复制leave
ret

这两条指令展开以后是：

assembly复制leave 等价于:
    mov rsp, rbp      ; rsp回到当前函数的栈底
    pop rbp           ; 从栈上弹出旧rbp，恢复调用者的rbp

ret 等价于:
    pop rip           ; 从栈顶弹出返回地址，写入rip，跳回调用者

这组操作非常精妙：

1. mov rsp, rbp直接让栈指针回到栈帧底。因为rbp在整个函数执行期间没变过，所以这一下就把之前sub rsp, 16分配的局部变量空间全部“释放”了，不需要一条条回收。注意，这里说的“释放”只是让rsp回到原位，栈上的数据还在，只是逻辑上不可用了。
2. pop rbp把调用者的rbp恢复回来。这样调用者继续执行时，它的栈帧底还是原来的那个。
3. pop rip把返回地址弹出来赋给rip。CPU接下来就会从返回地址继续执行，从而“回到”调用者。

到这一步，整个栈帧就销毁了。rsp回到了call add之前的位置，调用者接着执行下一条指令。整个过程中，add函数的局部变量c没有任何显式清理，只是被“遗忘”了。

5.3 三个值得注意的细节

第一个：如果编译器开了优化，函数可能根本不生成rbp，直接用rsp加偏移访问变量，收尾也只有一条ret。这种函数反汇编起来更简洁，但调试信息里局部变量和参数的位置更难对应。

第二个：_Noreturn函数（比如exit）不会执行返回路径，因为根本不会返回。编译器知道这一点，可能连调用者后续代码都不生成了。

第三个：在异常处理（如C++异常、setjmp/longjmp）中，栈帧销毁的时机比普通返回要复杂得多，因为异常可能让控制流跳过好几层函数。

6. 实操：写个例子看真实反汇编和栈变化

6.1 准备实验环境和编译参数

我建议你自己动手跑一遍，印象会深得多。实验环境只需要一个Linux系统（或者WSL），装好gcc和gdb，几分钟就能搞定。

以这个函数为例：

c复制#include <stdio.h>

int add(int a, int b)
{
    int c = a + b;
    return c;
}

int main(void)
{
    int sum = add(2, 3);
    printf("sum = %d\n", sum);
    return 0;
}

编译并生成反汇编：

bash复制gcc -g -o demo demo.c
objdump -d demo | grep -A20 "<add>:"

我实际跑出来的反汇编（gcc 11，不开优化）和前面列的基本一致。注意信息里的地址可能不同，但指令序列是标准的。

6.2 用gdb逐步观察栈的变化

启动gdb，在add函数入口下一个断点，运行到断点处，然后逐条执行并观察栈和寄存器：

bash复制gdb ./demo
(gdb) break add
(gdb) run
(gdb) info registers rsp rbp rip
(gdb) x/8gx $rsp

你会看到这样的输出：

code复制(gdb) x/8gx $rsp
0x7fffffffdff0: 0x0000000000000000  0x0000000000401156
0x7fffffffe000: 0x0000000000000000  0x0000000000401170
...

第一行第一个地址是rsp指向的位置，第二个0x401156就是调用者main中call add的返回地址。用ni（单步执行）一步一步走，分别执行push rbp、mov rbp, rsp、sub rsp, 16，每次执行完都再info registers rsp rbp，就能肉眼看到rsp向下挪动、rbp指向新位置的过程。

等函数执行到leave之前，再看一次x/8gx $rbp，栈上的内容大概是：

code复制rbp-12  c的值（0x00000005）
...
rbp     旧rbp值（指向main的栈帧）
rbp+8   返回地址 0x00401156

这时候你就亲手验证了前面画的那张图。

6.3 开了优化之后有什么区别

再用gcc -O2编一份：

bash复制gcc -g -O2 -o demo_O2 demo.c
objdump -d demo_O2 | grep -A10 "<add>:"

大概率会变成类似：

assembly复制add:
    lea    eax, [rdi+rsi]
    ret

没有push rbp，没有sub rsp，没有leave。整个函数栈帧都消失了。但这不代表函数没有栈帧概念，而是编译器经过分析，确定这个函数不需要在栈上保存任何东西，就直接把调用现场压缩到了寄存器和返回地址里。

遇到这种优化代码，你在gdb里依然可以用bt（backtrace）看到调用栈，因为gdb依赖的是调试信息（-g生成的），而不是运行时的rbp。如果连调试信息也去掉（strip处理过），那bt会显示不出来或者显示一堆??。

7. 常见问题与排查技巧实录

7.1 栈溢出：经常不是“栈不够大”那么简单

程序崩在“段错误”或者直接提示“stack smashing detected”，第一反应是检查是不是递归太深或者栈上用了超大数组。但我在实际排查中见过几个容易踩坑的场景：

• 在函数里声明了char buf[1024*1024]，1MB的数组放在栈上，某些环境下默认栈大小只有8MB，几个函数嵌套下来就爆了。这种大数组应该用malloc放到堆上，或者用static修饰变成静态存储区。
• 递归函数没有终止条件，或者终止条件很难达到。每次递归都在栈上压帧，栈空间是有限的，递归深度过高一样爆。可以用ulimit -s查看栈大小限制，用循环替代深度递归是更好的方案。
• 多线程程序里，线程栈大小可能默认只有1MB（pthread默认值），比主线程小很多，线程里用大局部变量更容易栈溢出。

排查栈溢出的有效手段是gdb的bt命令，它会列出当前调用链。如果看到同一个函数连续出现几十上百次，基本就是无限递归。

7.2 缓冲区溢出：为什么越界写会改掉“不相干”的变量

前面讲过，局部变量的排列是连续的。在小端序机器上，从低地址往高地址越界写，会依次覆盖其他局部变量、对齐填充、旧rbp、返回地址。

实际开发中遇到比较隐蔽的问题是：两个数组相邻，往第一个数组多写了一个字节，第二个数组的值被改掉了，但程序不立刻崩溃，而是在某个分支判断时出现了诡异行为。这种bug最难查，因为出错的地方和越界的地方离得很远。

推荐的排查思路：

1. 先用-fsanitize=address重新编译，这会给所有内存访问插桩，越界第一时间报告。
2. 或者在gdb里对可疑变量下硬件断点（watch），一旦值被改动就断下来，看是哪条指令改的。
3. 开启编译器的栈保护（-fstack-protector-strong），它在返回地址前插入canary，越界写先触发保护，程序会立即报错而不是悄悄跑飞。

我在教新人入门的时候，一定会让他们先把add这个例子的反汇编跑一遍，亲眼看看返回地址在栈上的位置，之后再讲缓冲区溢出，他们立刻就能明白为什么strcpy那么危险——因为它不检查目标缓冲区长度，写多了直接改写返回地址。

7.3 开优化后找不到变量：-fomit-frame-pointer的坑

有段时间我排查一个release版本的崩溃，gdb的bt完全不可用，函数调用链全是乱的。后来发现是编译时加了-O2并且默认启用了-fomit-frame-pointer，函数没有rbp帧指针了，gdb没法依靠运行时信息回溯调用链。

解决方案有两个：

1. 编译时加-fno-omit-frame-pointer，强制保留帧指针，调试信息更完整。
2. 依赖DWARF调试信息（-g）来重建调用栈，gdb会尝试从调试信息中推断栈帧布局，但反汇编可读性会差一些。

所以调试和发布最好分开编译，release版本追求性能没问题，但要留好符号表和调试信息，不然线上崩了只能干瞪眼。

7.4 栈上变量地址的诡异“随机化”

每次运行程序，局部变量的地址都可能不一样，这是ASLR（地址空间布局随机化）在起作用。这在排查栈相关问题时会让新手困惑：为什么这次崩溃的地址和上次不一样？

gdb默认会关闭ASLR方便调试，但程序直接运行时会开启。如果你写了一些依赖栈地址的程序（比如实验性的栈溢出利用代码），得先了解这一点，否则老以为是自己算错了偏移。

8. 一些实用性建议和我的个人体会

8.1 理解栈帧对调试的帮助是立竿见影的

我自己带新人时发现一个规律：真正理解栈帧的人，调试起崩溃问题来明显更快。因为他们看到bt里那些地址时，脑子里有画面——哪里是局部变量，哪里是返回地址，哪里可能被写坏了。而没这个概念的人，只能靠猜和试。

下次遇到奇怪的内存问题，别急着打日志，先停下来画一画当前函数的栈布局。变量声明顺序、数组大小、越界可能影响哪个变量，这些都能从布局图里直接读出来。

8.2 写底层代码时，栈对齐是隐形坑

如果你写的是普通应用代码，基本不用关心栈对齐。但一旦涉及内联汇编、手动构造函数调用、或者对接C库的某些接口（比如printf的格式串漏洞利用场景），栈对齐问题就会冒出来。

一个简单验证方法：在函数入口打印rsp % 16，看是不是8（进入函数但还没push rbp时）。如果不符合预期，说明前面某处的栈对齐被破坏了。

8.3 我踩过最经典的坑

有一阵子我在玩手写汇编实现的网络协议解析，为了性能直接在关键路径上写了一段内联汇编。功能测试全过，但放到生产环境上跑高并发，时不时就段错误。查了很久，最后发现是动态链接库回调函数时栈没对齐，某些路径下rsp%16不为8，触发了glibc里用movaps指令的代码，遇上了未对齐内存地址直接崩。

从那以后，我养成了一个习惯：凡是写底层代码涉及函数调用的地方，都会在关键入口处检查栈对齐。写汇编、写JIT、写C扩展，这个习惯帮我省下过不少排查时间。

8.4 后续可以自己尝试的扩展方向

看完这篇文章，你可以在本地尝试这几个方向加深理解：

• 写一个递归的factorial函数，断点停在递归深处，用bt和frame命令一层层往上跳，观察每一层的rbp和返回地址。
• 写一个故意越界写数组的函数，开-fstack-protector-strong编译，观察“stack smashing detected”是在哪个环节触发的。
• 尝试开-O3编译同一个函数，对比反汇编，看编译器如何优化掉栈帧。
• 有条件的话，用readelf --debug-dump=info看DWARF调试信息里函数和变量的描述，理解调试器是怎么从调试信息里还原栈帧布局的。

把这些实验做完，你对“函数栈帧”的理解就比大多数只会背概念的人扎实多了。底层的这些东西，看着和日常业务开发没关系，但关键时刻能救命——无论是排查线上崩溃、阅读反汇编，还是理解安全通告里的漏洞原理，都绕不开它。