2. 栈内存管理

栈这个东西，说白了就是程序运行时的「临时工作台」。我刚开始学嵌入式那会儿，总觉得栈就是个放局部变量的地方，没什么好研究的。直到有一次，一个递归函数把整个系统搞崩了，我才意识到——栈这东西，用好了是利器，用不好就是定时炸弹。

栈帧结构：函数调用的「现场记录」

每次你调用一个函数，CPU都会在栈上分配一块区域，这块区域就叫栈帧。它记录了函数执行所需的所有临时信息。

一个典型的栈帧包含这些内容：

• 返回地址：函数执行完后，该回到哪里继续执行
• 局部变量：函数内部定义的变量
• 保存的寄存器：调用者寄存器的备份
• 函数参数：部分参数通过栈传递

我画了一张图，帮你理解栈帧的布局：

你看这张图，main调用funcA，funcA又调用funcB。每次调用，栈顶指针就往下移，分配新的栈帧。返回的时候，栈顶指针往上移，释放栈帧。这就是所谓的「后进先出」。

局部变量的生命周期

局部变量的生命周期，说白了就是「从函数开始到函数结束」。我在项目中见过不少新手，喜欢把局部变量的地址返回给调用者，这就是典型的「悬空指针」问题。

// 错误示例：返回局部变量地址
int* get_value() {
    int x = 42;
    return &x;  // x 在函数返回后就被销毁了
}

// 正确做法：要么用静态变量，要么用堆内存
int* get_value_fixed() {
    static int x = 42;  // 静态变量，生命周期贯穿整个程序
    return &x;
}

为什么会这样？因为局部变量存储在栈帧中。函数返回时，栈帧被释放，那块内存就不再属于你了。虽然物理内存还在，但随时可能被其他函数覆盖。

我记得有一次调试一个串口通信程序，数据总是莫名其妙地出错。查了两天，最后发现是一个函数返回了局部数组的地址。那个数组在栈上，被下一个函数调用时覆盖了。嗯，从那以后，我养成了一个习惯：永远不返回局部变量的地址。

栈溢出：当临时工作台不够用时

栈溢出，就是你的程序试图使用超过栈大小的内存。嵌入式系统中，栈大小通常只有几KB到几十KB。你想想看，一个不小心，栈就爆了。

常见的栈溢出场景：

• 过大的局部变量：比如在函数内定义一个 10KB 的数组
• 过深的函数调用：递归调用层数太多
• 无限递归：递归没有终止条件

// 场景1：局部变量过大
void dangerous_func() {
    char buffer[1024 * 10];  // 10KB，嵌入式栈通常只有4-8KB
    // 直接栈溢出！
}

// 场景2：递归过深
int factorial(int n) {
    if (n == 0) return 1;
    return n * factorial(n - 1);  // n=10000时，栈帧堆叠10000层
}

我曾经在一个物联网项目中，遇到设备频繁死机的问题。排查了很久，最后发现是一个传感器数据处理函数里定义了一个 8KB 的临时缓冲区。而那个芯片的栈大小只有 4KB。每次调用这个函数，栈就爆了，系统直接复位。

递归陷阱：优雅但危险

递归确实很优雅，但代价是栈空间的消耗。每次递归调用都会创建一个新的栈帧。如果递归深度太大，栈空间就会被耗尽。

我整理了一个表格，帮你直观理解递归的栈消耗：

递归深度	栈帧大小（假设）	总栈消耗	风险等级
10	32 字节	320 字节	安全
100	32 字节	3.2 KB	注意
1000	32 字节	32 KB	危险
10000	32 字节	320 KB	必爆

你看这个表，递归深度到1000的时候，32KB的栈消耗已经让很多嵌入式系统吃不消了。我建议你：能用循环解决的问题，就别用递归。

但话说回来，有些问题用递归确实更直观，比如树的遍历。这时候怎么办？我的做法是：

1. 限制递归深度：加一个计数器，超过阈值就报错
2. 改用迭代：用显式的栈（堆内存）来模拟递归
3. 尾递归优化：如果编译器支持，尾递归可以复用当前栈帧

// 尾递归示例（编译器可能优化为循环）
int factorial_tail(int n, int acc) {
    if (n == 0) return acc;
    return factorial_tail(n - 1, n * acc);  // 尾调用
}

嗯，栈内存管理就讲到这里。记住一句话：栈是自动的，但不是无限的。用好它，别滥用它。