必须在FreeRTOSConfig.h中定义#define INCLUDE_uxTaskGetStackHighWaterMark 1（或新版本用INCLUDE_uxTaskGetStackHighWaterMark2 1）才能启用该函数，否则编译报错或返回无效值；调用时传NULL可查当前任务，返回值单位为“字”（32位系统需×4换算为字节），且须避开栈已严重不足时高频调用。
直接用 uxTaskGetStackHighWaterMark()，但必须配对启用宏、注意调用时机和单位换算——否则返回值毫无意义，甚至误导你加错栈大小。
怎么启用 uxTaskGetStackHighWaterMark 函数
这个函数默认是关闭的，不加宏就编译不过或返回 0。在 FreeRTOSConfig.h 中必须显式开启：
-
#define INCLUDE_uxTaskGetStackHighWaterMark 1（基础版本，FreeRTOS v10.3.0+ 推荐用下面这个） -
#define INCLUDE_uxTaskGetStackHighWaterMark2 1（推荐，支持传NULL查当前任务，且更稳定）
如果用的是较新版本（如 v10.5.1），只开 INCLUDE_uxTaskGetStackHighWaterMark2 就够了；老版本可能需两个都开。不开就链接时报 undefined reference to 'uxTaskGetStackHighWaterMark'。
怎么安全地获取某个任务的高水位线
函数原型是 UBaseType_t uxTaskGetStackHighWaterMark(TaskHandle_t xTask)，关键在参数传什么：
立即学习“C++免费学习笔记（深入）”；
- 传具体句柄（如
task1_handle）→ 查对应任务 - 传
NULL→ 查**当前正在运行的任务**（最常用，调试时直接塞进任务函数里就行） - 别传野指针或已删除任务的句柄，返回值不可靠
示例（放在某个任务函数里）：
void task1(void* pvParameters) {
for(;;) {
// ... 业务逻辑
UBaseType_t uxHighWaterMark = uxTaskGetStackHighWaterMark(NULL);
printf("Task1 stack watermark: %lu words (%lu bytes)\n",
(unsigned long)uxHighWaterMark,
(unsigned long)uxHighWaterMark * sizeof(StackType_t));
vTaskDelay(1000);
}
}注意：sizeof(StackType_t) 比硬写 *4 更稳妥，因为有些 Cortex-M0 平台栈类型是 16 位，portSTACK_TYPE 可能被重定义。
为什么返回值看起来“太小”或“一直为 0”
常见三类原因：
- 任务刚创建还没跑过几轮，栈没怎么用，高水位线接近满值（比如 256 字 → 正常）；等它处理一次网络包或递归解析 JSON 后再查
- 返回 0：大概率已溢出，或该任务从未成功调度过（比如优先级太低被饿死、创建失败没检查返回值）
- 返回值单位是“字”（word），不是字节——32 位系统上 1 word = 4 字节，但如果你误当字节看，会以为只剩 4 字节而恐慌加栈，其实还剩 16 字节
另外，这个函数本身要压栈执行，会临时消耗几个字，所以别在栈只剩 10 字时反复高频调用，否则可能自己把它压爆。
怎么结合 configCHECK_FOR_STACK_OVERFLOW 做交叉验证
uxTaskGetStackHighWaterMark() 是“体检”，configCHECK_FOR_STACK_OVERFLOW 是“报警器”，两者互补：
- 设为
2（推荐）：任务创建时填满栈底 16 字节为0xA5A5A5A5，每次任务切换检查是否被改写 → 能抓到大多数越界 - 必须实现钩子函数
vApplicationStackOverflowHook()，否则溢出时静默死机 - 一旦触发钩子，立刻用
uxTaskGetStackHighWaterMark()查所有任务，找出哪个任务的 watermark 已掉到个位数，基本就是它
真正容易被忽略的是：中断服务程序（ISR）也有自己的栈，而 uxTaskGetStackHighWaterMark() 查不到 ISR 栈。如果怀疑是中断嵌套导致的栈问题，得单独看 configISR_STACK_SIZE 或用芯片厂商的栈分析工具（如 STM32CubeIDE 的 Stack Usage 视图）。
