2. 堆栈溢出原理：堆栈生长方向、溢出类型与典型触发场景
好，咱们进入堆栈监控的核心话题——堆栈溢出。说实话，我在刚入行做嵌入式开发那会儿，对堆栈的理解就是“一个放局部变量的地方”。直到有一次，我在一个量产项目上，产品跑着跑着就莫名其妙复位了，查了整整三天，最后发现是堆栈溢出了。从那以后，我对堆栈的敬畏心就上来了。
今天这一节，咱们把堆栈溢出的原理彻底讲透。你搞懂了这些，后面再讲监控策略，就顺理成章了。
2.1 堆栈的生长方向——向上还是向下？
堆栈的生长方向，说白了就是“新数据往哪个方向放”。不同的处理器架构，习惯不一样。
- 向下生长（满递减）：这是最常见的。堆栈指针SP从高地址往低地址移动。每次压栈，SP先减，再存数据。ARM Cortex-M系列、x86都是这种。
- 向上生长（满递增）：SP从低地址往高地址移动。压栈时SP先加，再存数据。有些DSP或者老式处理器用这种。
- 空栈 vs 满栈：这个区别在于SP指向的是“最后一个有效数据”还是“下一个空闲位置”。满栈指向最后一个数据，空栈指向空闲位置。AUTOSAR里最常见的是满递减栈。
我个人习惯：在项目初期，第一件事就是确认芯片的堆栈生长方向。别小看这个，方向搞反了，你写的堆栈监控代码全白费。
举个例子，ARM Cortex-M的堆栈是满递减的。你声明一个局部变量，它在栈上的地址，比调用它的函数的局部变量地址要低。嗯，这个特性后面讲溢出检测时会用到。
2.2 堆栈溢出的两种类型——上溢与下溢
堆栈溢出，其实分两种。很多人只关注一种，忽略了另一种，结果踩坑。
2.2.1 堆栈上溢（Stack Overflow）
这是最常见的一种。函数调用太深，或者局部变量太大，堆栈指针跑出了预分配的堆栈区域边界。说白了，就是“栈用光了，还往里塞”。
后果是什么？数据写到堆栈以外的内存区域。可能是全局变量区，可能是堆区，甚至可能是代码区。程序行为立刻变得诡异——变量莫名其妙被改，函数返回地址被覆盖，然后就是HardFault或者看门狗复位。
我曾经在一个项目中，遇到一个任务堆栈只分配了512字节，结果里面有个函数用了400字节的局部数组。平时跑得好好的，一旦某个特定路径被触发，栈就爆了。查了整整两天，最后用堆栈填充法才定位到。所以，局部变量的大小，一定要心里有数。
2.2.2 堆栈下溢（Stack Underflow）
下溢相对少见，但一旦出现，比上溢更难查。它发生在堆栈指针退出了堆栈区域的低端边界。什么情况下会这样？
- 函数返回时，出栈操作比入栈操作多。比如中断嵌套时，保存和恢复上下文不匹配。
- 手动操作堆栈指针（比如某些汇编代码里直接改SP），改错了。
- 任务切换时，上下文保存/恢复逻辑有bug。
下溢的后果是：程序从错误的内存位置读取返回地址或数据，然后跳转到莫名其妙的地方去执行。嗯，这种bug通常表现为“随机跳飞”，非常难复现。
| 溢出类型 | 触发方向 | 典型后果 | 排查难度 |
|---|---|---|---|
| 上溢 | SP超出堆栈高端边界 | 数据覆盖、函数返回地址损坏、HardFault | 中等 |
| 下溢 | SP超出堆栈低端边界 | 程序跳飞、随机复位、上下文错乱 | 高 |
2.3 典型触发场景——我在项目中遇到的真实案例
理论讲完了，咱们聊聊实际。哪些场景最容易触发堆栈溢出？我列几个最常见的，你对照一下自己的项目。
场景一：递归调用
嵌入式里我一般不建议用递归。不是说不能用，而是你很难预估递归深度。有一次我接手一个项目，里面有个二分查找用了递归，输入数据量一大，栈直接爆了。你想想看，递归每调用一次，就压一次栈帧，深度不可控，风险极高。
避坑指南：如果非要用递归，一定要加深度限制。或者干脆改成循环实现。我个人习惯是，能不用递归就不用。
场景二：中断嵌套过深
高优先级中断打断低优先级中断，每嵌套一层，就要多压一份上下文。如果中断服务函数里再调用函数，栈消耗更大。我记得有个项目，中断嵌套到了4层，每层ISR里还调用了printf（千万别这么干！），结果栈直接爆了。
场景三：局部变量过大
这个最常见。比如在函数里声明了一个 uint8_t buffer[1024]，而任务栈总共才2048字节。再加上函数调用链上的其他栈消耗，很容易就超了。我建议，大数组用静态分配或者动态分配，别放栈上。
场景四：任务栈分配不合理
在AUTOSAR或者RTOS环境下，每个任务都有自己的栈。如果某个任务的栈分配得太小，而它的执行路径又复杂，溢出是迟早的事。反过来，分配太大又浪费RAM。所以，栈大小的估算，需要结合调用树和局部变量大小来算。
我建议：项目初期，给每个任务多分配20%~30%的余量。等后期用堆栈监控工具测出实际使用峰值后，再优化调整。别一开始就抠抠搜搜的，省那几十字节，后面查bug的时间成本高得多。
2.4 堆栈溢出的本质——为什么它这么难查？
堆栈溢出难查，原因在于：它不会立即崩溃。很多时候，栈溢出了，程序还能继续跑一会儿。因为溢出的数据可能先覆盖了不常用的全局变量，或者覆盖了某个暂时不用的内存区域。等到真正用到那块内存时，程序才崩溃。这时候，崩溃点和溢出点已经隔了十万八千里。
你想想看，一个变量在A函数里被栈溢出改写了，但直到B函数里才用到这个变量，然后程序挂了。你查bug时，盯着B函数看半天，怎么也找不到原因。这就是堆栈溢出最坑的地方。
嗯，所以下一节我们要讲的堆栈监控机制，核心目的就是：在溢出发生的那一刻就抓住它，而不是等它酿成大祸。
好了，这一节的内容就到这里。堆栈的生长方向、上溢和下溢的区别、以及典型触发场景，你都记住了吗？下一节，我们聊聊具体的堆栈监控实现方法——怎么在AUTOSAR BSW里把堆栈看住。