面试官问："你们的项目堆栈多大？怎么判断会不会溢出？"你是不是脱口而出"分配大一点就行了"？说实话，这个问题我当年也答得很烂，直到真正踩过坑才发现，堆栈溢出这东西，表面上看是空间不够，实际上涉及函数调用、中断嵌套、局部变量一大堆细节。今天就跟大家聊聊，怎么系统地排查堆栈溢出，面试的时候怎么答才能加分。
一、先搞清楚堆栈到底是什么
很多教材把堆栈讲得很玄乎，什么"后进先出"、"向上增长向下增长"，说实话新人听着容易懵。按我的经验，你就记住三个东西：**SP指针**、**栈帧**、**函数调用**。
SP指针（Stack Pointer）就是指向当前栈顶的那个寄存器，CPU每Push一个数据，SP就往指定方向挪一格。栈帧呢，就是每次调用函数时在栈上划的一块地儿，用来存返回地址、参数、本地变量这些。函数执行完，这块地儿就释放，SP回到原来的位置。
图1 堆栈内存结构与函数调用关系
说起来简单，但出问题往往就出在这些地方：递归调用太深、中断里又调函数、局部数组太大……任何一个环节失控，SP就可能越过边界。
二、这几个坑最容易踩
想排查溢出，得先知道什么情况会导致溢出。按我的经验，下面这几类是高频雷区：
1. 递归调用过深—— 这个最典型，特别是没加递归终止条件或者递归层数没控制好。按我的测试，STM32这种32位MCU，每层递归至少占几十字节，递归100层可能就吃掉好几KB。
2. 局部大数组—— 很多人习惯在函数里定义大数组当缓冲区，比如char buf[1024]。这种东西全压在栈上，多调几次直接爆。
3. 中断嵌套—— 进了中断又调函数，如果中断优先级还嵌套，每层都得重新压栈。按我的经验，高优先级中断嵌套3层以上就得仔细算算了。
4. 参数和局部变量太多—— 函数参数超过一定数量，有些编译器会用栈来传参，加上各种局部变量，栈帧可能比你想象的大得多。
图2 堆栈溢出的三大元凶
⚠容易忽略的点
很多新手以为"溢出就是程序跑飞"，其实不然。有时候溢出了一点，程序还能跑，但数据悄悄被破坏了，这种软故障排查起来才头疼。
三、排查方法从易到难
遇到疑似溢出的情况，按这个顺序来排查，一般能定位到问题。
1. 观察法 —— 最直接
如果你的MCU有调试器，第一步就是观察SP的值。在IDE里（比如Keil的Watch窗口）盯着SP，看它是不是一直往一个方向涨。特别是调用一个复杂的函数后，SP有没有明显变化，这个最说明问题。
有些项目还会在关键位置打印SP值：
printf("SP=0x%08X\n", __get_MSP());
说实话，加这种日志对定位问题帮助很大，我每次调嵌入式项目都会在入口和中断里打几个SP日志。
2. 计算法 —— 算清楚
光看不行，还得算。编译器生成的MAP文件里，一般能找到"Maximum Stack Size"这个信息。这代表整个程序运行过程中，最大栈用量是多少。
按我的经验，看MAP文件重点关注这几个：
函数最大栈用量：每个函数的栈帧大小
中断栈用量：所有中断嵌套可能占的最大空间
主栈+进程栈的总量：确认有没有跑到边界
3. 工具法 —— 用专业手段
图3 堆栈溢出排查四步法
现在很多IDE都有栈分析工具，比如IAR的Stack Usage、Keil的Stack Meter。这些工具能自动算出各路径的最大栈用量，比手工算准多了。
有些RTOS还提供运行时栈水位检测功能，能在栈快要溢出的时候给你报警。这个对防止生产环境出问题特别有用。
4. 经验法 —— 避坑指南
说几个我踩过无数次的坑：
大数组尽量用静态变量或者全局变量，别放栈上
中断服务函数（ISR）里尽量别调大函数，能放外边就放外边
递归能不用就不用，非得用的话设个最大深度保护
分配栈空间的时候，一般给理论最大值乘以1.5到2倍的余量
💡小技巧
有个土办法可以快速定位栈是否够用：在.bss段放一个固定值（比如0xAA），程序跑一段时间后，检查这个区域有没有被改写。如果被改写了，说明栈膨胀到这里了。
四、面试怎么答才加分
回到面试的场景。面试官问堆栈溢出问题，其实考的不是你会"分配大空间"这种简单答案，他想知道你**分析问题**和**解决问题**的思路。
按我的经验，分层回答效果最好：
第一层：现象描述"堆栈溢出通常表现为程序跑飞、数据被破坏、HardFault异常等。"
第二层：原因分析"常见原因有递归过深、局部大数组、中断嵌套等，我会通过观察SP变化和分析MAP文件来定位瓶颈。"
第三层：解决思路"优化方案包括：大数组改为静态/全局、减少ISR嵌套、计算实际栈需求并预留余量、使用栈检测工具等。"
第四层：预防措施"从源头避免：代码规范约束（ISR不调大函数）、CI阶段做栈分析、运行时加水位检测。"
说实话，能答到第三层、第四层的人不多，这也是为什么很多人面试完觉得还行但没下文。技术面试考的就是深度，你得让人感觉你对这个问题有**系统性的思考**，而不只是会用。
五、预防比排查更重要
排查是亡羊补牢，预防才是根本。说几个工程实践中比较有效的做法：
代码规范：明确规定ISR里不许调哪些API，大数组必须用static修饰
编译检查：CI/CD里加栈分析，溢出直接报错不让合并
静态分析：定期跑工具扫描，生成栈使用报告
运行时监控：产品上线后开启栈水位检测，异常时记录日志
说起来都是常规操作，但坚持执行下去的项目，堆栈问题真的很少见。
📋快速检查清单
SP指针位置对不对，有没有持续增长
MAP文件看了没，最大栈用量心里有数
大数组有没有上静态区
中断嵌套层数控制住没
代码规范有没有约束
好了，关于堆栈溢出排查就聊到这里。这个问题说难不难，说简单也不简单，关键是得有系统的方法。下次面试再被问到，希望你能答得漂亮。
—— END ——
