4. 调用栈分析：读懂调用栈、栈帧与作用域、常见栈溢出问题
调用栈，说白了就是程序运行时的「函数调用记录本」。
我刚开始做调试那会儿，看到一堆堆栈信息就头大。后来被一个线上崩溃问题折磨了三天，才真正意识到——读懂调用栈，是调试的基本功。
4.1 调用栈是什么？
程序执行时，函数是一层一层调用的。每次调用一个函数，系统就会在内存中划出一块区域，用来存放这个函数的局部变量、参数、返回地址等信息。这块区域，就叫栈帧。
多个栈帧叠在一起，就是调用栈。
举个例子：
void funcA() {
int a = 1;
funcB();
}
void funcB() {
int b = 2;
funcC();
}
void funcC() {
int c = 3;
// 断点停在这里
}当程序停在 funcC 里时，调用栈从底到顶是：
- main → funcA → funcB → funcC
每个函数都有自己的栈帧，互不干扰。
核心要点：调用栈是后进先出的结构。最后一个调用的函数，最先返回。
4.2 栈帧里有什么？
一个典型的栈帧，包含这几样东西：
| 组成部分 | 说明 |
|---|---|
| 局部变量 | 函数内部定义的变量 |
| 参数 | 调用时传入的参数 |
| 返回地址 | 函数执行完后，回到哪里继续执行 |
| 基址指针 | 指向当前栈帧的起始位置 |
我个人习惯在调试时，先看栈帧里的局部变量。很多时候，问题就出在某个变量值不对。
小技巧：在 IDE 里双击调用栈的某一行，就能跳转到对应的函数上下文。这时候局部变量窗口会自动刷新，非常方便。
4.3 作用域与栈帧的关系
作用域，说白了就是变量的「可见范围」。
每个栈帧对应一个作用域。函数内部的变量，只能在当前栈帧里访问。出了这个函数，变量就销毁了。
嗯，这里要注意：
- 全局变量不在栈上，在静态存储区
- 堆上的变量需要手动管理，跟栈没关系
- 局部变量的生命周期，就是栈帧的生命周期
我曾经遇到过一个 bug：一个函数返回了局部变量的地址。调用方拿着这个地址去读数据，读到的全是垃圾值。为什么？因为那个栈帧已经被回收了。
警告：永远不要返回局部变量的指针或引用！这是 C/C++ 新手最容易犯的错误之一。
4.4 常见栈溢出问题
栈溢出，就是栈空间用完了。为什么会这样？
我总结了几种常见情况：
- 无限递归——函数自己调用自己，没完没了
- 局部变量太大——比如在栈上声明了一个 10MB 的数组
- 嵌套调用太深——函数一层套一层，栈帧叠得太高
来看一个典型的无限递归：
void crash() {
int x = 0;
crash(); // 自己调用自己，永不返回
}运行这段代码，很快就会出现 Stack overflow 错误。
你想想看，每次调用 crash()，系统都要分配一个新的栈帧。栈空间是有限的（通常是 1MB 到 8MB），用完了就崩了。
避坑指南：我曾经接手过一个项目，里面有个递归函数处理树形结构。数据量小的时候没问题，一上线数据量大了，直接栈溢出。后来改成迭代实现，问题就解决了。
4.5 如何分析调用栈？
拿到一个崩溃日志，调用栈信息怎么看？
我的习惯是：
- 先看最顶层的函数——那是崩溃发生的地方
- 再看调用链——从 main 到崩溃点，一路经过了哪些函数
- 关注参数值——有时候参数传错了，一路带偏
举个例子，假设崩溃日志显示：
#0 0x00007f... in processData (data=0x0)
#1 0x00007f... in handleRequest (req=...)
#2 0x00007f... in main (argc=1, argv=...)看到 data=0x0 了吗？空指针。问题出在 processData 里传入了空指针。再往上查，handleRequest 调用时就没检查参数是否合法。
提示：很多调试器支持直接点击调用栈的每一行，跳转到对应的源代码位置。善用这个功能，能省不少时间。
4.6 知识体系总览
下面这张图，把调用栈的核心知识点串起来了：
4.7 实战建议
最后，分享几个我自己的经验：
- 遇到崩溃，第一件事就是看调用栈。别急着改代码
- 学会在调试器里设置条件断点，能精准定位问题
- 递归函数一定要有终止条件，并且考虑栈深度
- 大数组尽量用堆（malloc/new），别放在栈上
记住：调用栈是调试的「地图」。看不懂地图，你就永远在迷路。
好了，这一章就到这里。调用栈这块，说白了就是多练。看多了，自然就熟了。