栈大小估算：静态分析函数调用链、局部变量大小、中断嵌套深度
好，咱们进入第三个实战题目。栈大小怎么估？说实话，这是很多VxWorks开发者最头疼的事。我见过不少项目，前期拍脑袋给个栈大小，结果跑起来三天两头栈溢出，查得人想砸键盘。
静态分析，说白了就是靠脑子算。你想想看，一个任务从创建到销毁，它走过的函数调用链有多深？每个函数里又声明了多少局部变量？再加上中断一进来，栈又被吃掉一块。把这些都算清楚，你才能给出一个靠谱的栈大小。
函数调用链的深度分析
先看调用链。每个函数调用，都会在栈上压入返回地址、保存的寄存器、还有局部变量。调用链越长，栈消耗越大。
我个人习惯，先画出任务的主干调用路径。比如一个数据采集任务：
taskDataCollect()
├── sensorInit() // 初始化传感器
│ └── i2cConfig() // 配置I2C
│ └── i2cWriteReg() // 写寄存器
├── sensorRead() // 读取数据
│ └── i2cRead() // I2C读取
│ └── i2cWait() // 等待传输完成
└── dataProcess() // 数据处理
└── fftTransform() // FFT变换
└── fftBitReverse() // 位反转
这条链最深是4层调用。但注意，有些函数内部还有条件分支。比如i2cWait()里可能调用了taskDelay()，而taskDelay()又会触发内核调度。嗯，这里要小心——内核调度本身不消耗任务栈，但taskDelay()的调用路径会。
关键点：调用链深度取最大值，不是平均值。你永远不知道系统在哪个最坏情况下会走最深的那条路。
局部变量大小的精确计算
局部变量是栈消耗的大头。每个函数里声明的数组、结构体，都会在栈上分配空间。我建议你养成习惯，写代码时就估算每个函数的栈帧大小。
举个例子：
void dataProcess(void)
{
uint8_t buffer[1024]; // 1KB
struct SensorData data; // 假设32字节
float fftResult[256]; // 1KB (float占4字节)
int i, j; // 8字节
// 总共约 2KB + 40字节
}
你看，光这一个函数就吃掉2KB多。如果调用链上有三四个这样的函数，栈大小很快就上去了。
我在项目中遇到过最夸张的情况——一个同事在中断服务函数里声明了一个2KB的数组。我当时就问他：「你知道中断栈和任务栈是共享的吗？」他一脸懵。后来我们花了整整两天排查一个随机崩溃的问题，最后发现就是这2KB数组惹的祸。
小技巧：用checkStack工具或者taskShow命令，可以查看任务栈的实际使用峰值。但注意，这只能看到运行时的数据，静态分析能帮你提前发现问题。
中断嵌套深度的栈消耗
中断嵌套，这是栈溢出的重灾区。VxWorks里，中断处理默认使用当前任务的栈。也就是说，任务A正在跑，突然来了中断ISR1，ISR1还没处理完，又来了更高优先级的中断ISR2。这时候，ISR2的栈帧就压在ISR1上面，而ISR1的栈帧又压在任务A的栈上。
你想想看，如果嵌套三层中断，每层中断消耗500字节，那任务栈就要额外多预留1.5KB。
| 中断层级 | 典型栈消耗 | 说明 |
|---|---|---|
| 一级中断 | 200-400字节 | 保存上下文 + 简单处理 |
| 二级中断 | 400-800字节 | 嵌套后上下文保存更多 |
| 三级中断 | 800-1600字节 | 深度嵌套，风险极高 |
我曾经在一个通信基站项目里，遇到过五级中断嵌套。当时系统偶尔重启，查了两个月没找到原因。后来我用逻辑分析仪抓中断时序，才发现有一个低优先级中断里调用了printf()，而printf()内部又触发了串口中断，串口中断又调用了信号量操作……最后栈直接爆了。
避坑指南：我曾经在中断服务函数里调用semGive()，以为没问题。结果那个信号量触发了更高优先级的任务，任务又调用了文件系统操作，文件系统操作又产生了中断……死循环了。记住：中断里尽量只做最轻量的事，别搞复杂调用。
综合估算公式
好了，把上面三部分加起来，我们可以得到一个估算公式：
任务栈大小 = 最大调用链栈帧和 + 中断嵌套最大消耗 + 安全余量
其中：
最大调用链栈帧和 = Σ(每个函数的局部变量 + 返回地址 + 寄存器保存)
中断嵌套最大消耗 = Σ(每层中断的栈消耗)
安全余量 = 上述总和的 20%-30%
举个例子：
- 调用链最深4层，总栈帧约3KB
- 最多嵌套2层中断，每层约500字节，共1KB
- 安全余量取25%，即 (3KB + 1KB) × 25% = 1KB
- 建议栈大小 = 3KB + 1KB + 1KB = 5KB
嗯，这里要注意。安全余量不是拍脑袋的。我一般会根据任务的实时性要求来调整。实时性高的任务，余量多留一些；后台任务可以少留一点。
核心原则：栈大小宁大勿小。多给256字节可能浪费一点内存，但少给256字节可能导致系统崩溃。在资源允许的情况下，我建议至少留30%的余量。
实战建议
最后给你几个实操建议：
- 画调用链图——用纸笔或者画图工具，把任务的所有可能调用路径画出来。别偷懒，这一步能帮你发现很多隐藏的调用关系。
- 标注局部变量——在每个函数旁边标注局部变量的大小。数组、结构体、缓冲区是重点关注对象。
- 分析中断嵌套——搞清楚系统中哪些中断可能嵌套，嵌套深度是多少。如果可能，尽量降低中断嵌套深度。
- 运行验证——估算完成后，用
taskShow或者checkStack工具跑一下实际负载，看看峰值栈使用量是否在安全范围内。
说白了，栈大小估算就是一场「算账」的活。你把每一笔开销都算清楚，心里就有底了。我做了十几年嵌入式，踩过的坑不计其数，但自从养成静态分析的习惯后，栈溢出问题几乎再没出现过。
下一节，咱们聊聊动态监测的方法。静态分析是「纸上谈兵」，动态监测才是「真刀真枪」的验证。