FreeRTOS栈溢出钩子需同时满足configCHECK_FOR_STACK_OVERFLOW设为1或2、且正确定义extern "C"声明的vApplicationStackOverflowHook函数才生效；模式1仅任务切换时检查栈指针越界，漏检率高，模式2额外校验栈底魔数0xA5，更敏感但仍有盲区，二者均非万能，须结合静态分析与MPU等多层防护。
FreeRTOS 的 Stack Overflow Hook 是嵌入式 C++ 项目中最常用、最轻量的运行时堆栈溢出检测手段，但它极易被误配或误判——启用后没反应，不代表安全；有反应，也不代表问题已定位。
FreeRTOS 中 Stack Overflow Hook 怎么启用才生效
它不是“打开就报警”的开关，而是依赖两个关键条件同时满足：
-
configCHECK_FOR_STACK_OVERFLOW必须设为1或2（不能是0） - 必须提供用户定义的函数
vApplicationStackOverflowHook，且函数签名严格匹配：void vApplicationStackOverflowHook( TaskHandle_t xTask, signed char *pcTaskName ) - 该函数不能是 inline、不能在类内部定义（C++ 类成员函数带隐式
this参数，会链接失败） - 如果使用 C++ 编写，需用
extern "C"包裹声明和定义，避免 C++ name mangling 导致链接不到
configCHECK_FOR_STACK_OVERFLOW = 1 和 = 2 的实际区别
两者检测时机与覆盖范围完全不同，选错等于白开：
-
= 1：只在每次任务切换（context switch）前，检查当前任务的栈顶是否被破坏（即 SP 是否低于栈起始地址）。快，但漏检率高——比如高优先级任务长期独占 CPU，溢出后根本不会切出，就永远不触发 -
= 2：除做=1的检查外，还会在每次任务切换时，扫描任务栈底部固定区域（通常是最后 16 字节），看是否仍为初始化时填入的魔数0xA5。更敏感，但仍有致命盲区：若溢出是“跳过”底部直接砸进相邻内存（如大数组分配），0xA5区域毫发无损，Hook 就完全静默
实践中，=2 是底线选择，但绝不能把它当作唯一防线。
Hook 触发后为什么程序常直接死机而不是进入调试
因为 vApplicationStackOverflowHook 本身也运行在出问题的任务栈上——此时栈已损坏，任何局部变量、函数调用甚至 printf 都可能再次触发异常。常见错误包括：
- 在 Hook 里调用
HAL_Delay、vTaskDelay等需要栈空间的 RTOS API - 尝试用
snprintf格式化任务名并打印，触发栈二次溢出 - 未禁用中断就操作外设（如 UART 发送），导致 ISR 入栈失败
可靠做法是：仅做最小动作——点亮 LED、写 GPIO、触发 NMI 或写入备份寄存器，然后死循环或调用 __BKPT(0) 进入调试器。任何“优雅退出”逻辑，在栈已破的前提下都是幻觉。
Stack Overflow Hook 只是最后一道软性警报
它无法阻止溢出发生，也无法精确定位哪行代码越界。真正有效的防护必须分层：静态阶段靠 uxTaskGetStackHighWaterMark 定期采样水位；部署前用 MPU 划定栈边界触发 MemManageFault；对关键任务强制使用静态分配+编译期栈大小断言。Hook 的唯一价值，是让系统在失控前留下一个可捕获的“临终信号”——别指望它救活任务，只让它帮你把 bug 挖出来。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
