4、静态分析方法：通过代码静态分析估算最大堆栈深度
静态分析，说白了就是不动用硬件，光靠看代码来算堆栈深度。我刚开始做实时系统那会儿，觉得这方法挺玄乎的——代码还能算出堆栈用多少？后来踩了几次坑才明白，这其实是性价比最高的手段。
你想想看，动态测试你得跑起来才知道，万一跑飞了，现场全丢。静态分析不一样，编译完就能出结果，省时省力。我个人习惯是在代码评审阶段就做一轮静态分析，把明显的问题先揪出来。
4.1 基本原理
静态分析的核心思路很简单：把函数调用链上每个函数的堆栈帧大小加起来。每个函数都有自己的局部变量、参数、返回地址，这些都要占堆栈空间。
举个例子：
void funcA() {
int a; // 4字节
char buf[32]; // 32字节
funcB();
}
void funcB() {
long x; // 8字节
funcC();
}
void funcC() {
short y; // 2字节
// 没有更多调用
}如果从 funcA 开始调用，堆栈深度就是：funcA(4+32+8) + funcB(8+8) + funcC(2+8)。注意那个 +8 是返回地址和可能的对齐开销。嗯，这里要注意，不同架构的对齐规则不一样，ARM和RISC-V就有差别。
4.2 手动分析方法
对于小项目，手动分析完全可行。我早期做8位机项目时，代码量也就几千行，拿张纸就能画出来。
步骤是这样的：
- 画出调用关系图——从main函数开始，看每个函数调用了谁
- 找出所有调用路径——特别是那些递归和回调
- 计算每条路径的堆栈深度——把沿途函数的帧大小加起来
- 取最大值——这就是理论上的最大堆栈深度
关键点：中断处理函数也要算进去。我见过太多人只算主流程，忘了中断，结果一开中断就崩。
我曾经在一个项目中，手动分析发现某条路径深度是 512 字节，但实际只分配了 384 字节。查了半天，原来是一个回调函数嵌套了三级，每级都开了个大数组。嗯，这种问题手动分析很容易漏掉。
4.3 工具辅助分析
项目大了，手动分析就不现实了。这时候得靠工具。我常用的工具有这么几类：
| 工具类型 | 代表工具 | 适用场景 |
|---|---|---|
| 编译器内置 | GCC -fstack-usage | 快速估算，适合开发阶段 |
| 静态分析器 | StackAnalyzer、CodeSonar | 精确分析，适合安全关键系统 |
| 开源工具 | GCC -Wstack-usage= | 轻量级检查，适合小团队 |
我个人最常用的是 GCC 的 -fstack-usage 选项。编译时加上它，会生成一个 .su 文件，里面记录了每个函数的堆栈使用量。
// 编译命令
arm-none-eabi-gcc -fstack-usage -c main.c -o main.o
// 生成的 main.su 文件内容
main.c:5:5:funcA 32 static
main.c:10:5:funcB 16 static
main.c:15:5:funcC 8 static拿到这些数据后，再结合调用关系图，就能算出最大深度。不过要注意，-fstack-usage 只算局部变量和参数，没考虑中断嵌套。所以实际分配时要留余量。
小技巧：用 -Wstack-usage=256 可以让编译器在函数堆栈超过 256 字节时报警。我习惯把这个值设成堆栈总大小的 1/4，超过就警告，逼着自己优化。
4.4 递归函数的处理
递归是静态分析的噩梦。为什么？因为递归深度在编译时是未知的。比如：
void recursive_func(int n) {
char tmp[64];
if (n > 0) {
recursive_func(n - 1);
}
}这个函数每递归一次就消耗 64+8 字节。如果 n 最大是 10，那深度就是 720 字节。但如果 n 来自外部输入，那就没法静态确定了。
我建议的做法是：
- 能不用递归就不用——实时系统里递归是毒药
- 必须用的话，加深度限制——比如用静态变量计数，超过阈值就报错
- 分析时按最大可能深度算——宁可多估，不能少算
警告：千万别在中断服务函数里用递归！我曾经在一个项目中看到有人在 ISR 里用了递归，结果中断一触发，堆栈直接爆掉，系统复位。查了两天才找到原因。
4.5 静态分析的局限性
静态分析不是万能的。我总结了几点要注意的地方：
- 函数指针调用——编译器不知道你调了谁，得靠人工标注
- 动态内存分配——malloc 的堆栈开销没法静态算
- 汇编代码——手写汇编的堆栈使用量，工具算不出来
- 优化影响——不同优化级别下，堆栈使用量可能差很多
说白了，静态分析给出的是「理论值」，实际运行中可能因为中断嵌套、异常处理等因素，实际深度更大。所以我一直强调：静态分析的结果要乘以 1.5 的安全系数，再作为堆栈分配的依据。
4.6 实战建议
最后给几条我自己的经验：
- 每次代码提交都跑一次静态分析——集成到 CI 流程里，自动检查
- 把堆栈深度作为代码评审的必查项——特别是新增了函数调用链
- 保留分析报告——方便后续排查问题时回溯
- 结合动态测试验证——静态分析是「算」，动态测试是「测」，两者互补
嗯，静态分析这块就讲这么多。下一章我们聊聊动态测量方法，那又是另一套思路了。