第二讲：栈空间计算——如何估算任务栈大小？任务栈、中断栈与系统栈的区别
大家好，欢迎来到第二讲。
上一讲我们聊了栈溢出有多可怕。有同学问我：“老师，到底怎么算一个任务该分配多少栈？”
这个问题问得好。说实话，我刚入行时也踩过这个坑。我记得第一次用FreeRTOS做项目，任务栈全凭感觉给——128、256、512随便填。结果呢？产品跑到一半就死机了。查了三天，最后发现是栈溢出了。
从那以后，我再也不敢“凭感觉”了。今天我们就来彻底讲清楚：栈空间到底怎么算？任务栈、中断栈、系统栈有什么区别？
一、任务栈大小估算：从“玄学”到“科学”
任务栈的大小，说白了就是任务运行时“临时放东西”的空间。函数调用、局部变量、中断嵌套，全都要往这里塞。
我个人习惯用“三步法”来估算：
- 先算函数调用链的最大深度
- 再算局部变量和临时数据
- 最后加上中断嵌套的余量
举个例子。假设你的任务里调用了三个函数：A调用B，B调用C。每个函数有4个参数（32位），局部变量加起来200字节。那么栈空间至少需要：
// 函数调用链深度：3层
// 每层返回地址：4字节（ARM Cortex-M）
// 每层参数：4个 × 4字节 = 16字节
// 局部变量：200字节
// 中断嵌套：假设最大嵌套2层，每层保存8个寄存器 × 4字节 = 32字节
最小栈 = 3 × (4 + 16) + 200 + 2 × 32
= 60 + 200 + 64
= 324 字节嗯，这里要注意：这只是理论最小值。我建议至少翻一倍，也就是给到648字节。为什么？因为运行时还有临时变量、编译器优化、以及你没想到的库函数调用。
实战经验：我在项目中遇到过，一个看起来只用了200字节栈的任务，实际运行时峰值达到了500字节。所以我的经验法则是：理论值 × 2，再向上取整到最近的2的幂次。
小技巧：FreeRTOS提供了uxTaskGetStackHighWaterMark()函数。你可以在任务运行一段时间后调用它，看看还剩多少栈空间。这个值就是“水位线”，越低说明栈越紧张。
二、任务栈 vs 中断栈 vs 系统栈：它们到底有什么区别？
很多初学者会把这三个概念搞混。我刚开始学的时候也犯过这个错。你想想看，它们都叫“栈”，但用途完全不同。
| 栈类型 | 用途 | 谁在使用 | 典型大小 |
|---|---|---|---|
| 任务栈 | 任务运行时的临时数据 | 每个任务独立拥有 | 256~4096字节 |
| 中断栈 | 中断服务程序（ISR）的临时数据 | 所有ISR共享 | 512~2048字节 |
| 系统栈 | 内核调度、系统调用 | FreeRTOS内核使用 | 由configMINIMAL_STACK_SIZE定义 |
任务栈是每个任务私有的。你创建任务时指定的栈大小，就是任务栈。任务切换时，CPU的寄存器状态会保存到当前任务的栈里。
中断栈比较特殊。在ARM Cortex-M上，中断发生时硬件会自动压栈8个寄存器。如果中断嵌套，每一层都要压一次。我建议中断栈至少给512字节，如果中断处理复杂，给到1024更稳妥。
系统栈是内核自己用的。比如任务切换时的调度函数、队列操作、信号量操作，都会用到系统栈。这个栈通常由configMINIMAL_STACK_SIZE定义，默认一般是128字节。但说实话，128字节在复杂系统中很容易溢出。我一般给到256。
警告：千万不要把任务栈和中断栈混在一起用！我曾经见过一个项目，为了省内存，让中断和任务共用栈。结果中断一嵌套，任务的数据就被覆盖了。查了整整一周才找到原因。
三、如何精确测量栈使用量？
估算终究是估算。真正靠谱的做法是：先估算，再测量，最后调整。
FreeRTOS提供了两个非常有用的API：
// 获取任务栈的剩余空间（水位线）
UBaseType_t uxTaskGetStackHighWaterMark(TaskHandle_t xTask);
// 获取整个堆的使用情况
size_t xPortGetFreeHeapSize(void);我通常的做法是：
- 先给任务分配一个较大的栈（比如1024字节）
- 运行所有功能场景，包括最极端的情况
- 调用uxTaskGetStackHighWaterMark()查看最低水位
- 根据最低水位，把栈大小调整到“最低水位 + 安全余量”
安全余量我一般留20%~30%。比如最低水位是200字节，那栈大小就给到256或320。
避坑指南：我曾经在一个项目中，测量时水位线显示还剩300字节，觉得绰绰有余。结果产品上线后，用户反馈偶尔死机。后来发现是某个极端场景下，中断嵌套深度比测试时多了一层。从那以后，我每次都会在“最坏情况”下测量，而不是“正常情况”。
四、常见误区与最佳实践
最后，我总结几个常见误区，你对照看看自己有没有中招：
- 误区一：栈越大越好。错！每个任务栈都是RAM，嵌入式设备RAM有限。给太大浪费，给太小崩溃。
- 误区二：所有任务用一样的栈大小。错！不同任务复杂度不同，应该分别估算。
- 误区三：中断栈不用管。错！中断栈溢出同样会导致系统崩溃，而且更难排查。
- 误区四：系统栈用默认值就行。错！如果你的系统任务很多、调度频繁，默认值可能不够。
我的最佳实践是：
- 每个任务单独估算栈大小，不要一刀切
- 中断栈至少给512字节，复杂系统给1024
- 系统栈从256字节起步，根据实际情况调整
- 每次修改代码后，重新测量栈使用量
- 在开发阶段开启栈溢出检测（下一讲会详细讲）
好了，这一讲的内容就到这里。栈空间计算其实不难，关键是要养成“先估算、再测量、后调整”的习惯。下一讲我们聊聊如何用FreeRTOS自带的工具检测栈溢出，以及如何编写不会溢出的代码。
记住：栈空间不是玄学，是科学。你掌握了方法，就不会再被栈溢出折磨了。