一、底层原理：栈溢出为什么会发生？

栈是 MCU 中用于存储函数调用上下文、局部变量、中断现场的核心内存区域，主流 ARM Cortex-M 系列 MCU 采用向下增长栈设计：栈从高地址向低地址扩展，栈指针 SP 始终指向当前栈顶部。

典型的栈帧布局如下：

高地址 -> 函数返回地址（函数调用结束后需要回到的指令地址）
         父函数栈帧指针FP（用于栈帧回溯）
         函数入参（部分架构通过寄存器传递）
         局部变量、数组、结构体等
低地址 -> 中断现场寄存器（中断触发时自动入栈）
         <-- 当前栈指针SP指向这里

当函数调用深度增加、局部变量过大、中断嵌套层数过多时，栈指针会不断向低地址移动，一旦超出栈的合法边界，就会触发栈溢出。根据溢出程度的不同，会产生两类完全不同的表现：

1. 显性溢出：栈空间完全耗尽，SP 指向非法内存区域，直接触发 HardFault 异常，程序崩溃，这类问题排查难度较低，有明确的崩溃现场。
2. 隐性溢出：仅溢出少量字节，覆盖了栈边界外的全局变量或堆数据，不会立即崩溃，但会导致全局变量无故被篡改、逻辑功能异常，且问题偶发，排查难度极高。

二、为什么嵌入式场景栈溢出特别难排查？

同样是内存越界问题，嵌入式场景下的栈溢出排查难度远高于堆溢出，核心原因有四点：

1. 栈空间极小：根据 NXP、ST 官方 MCU 文档，普通嵌入式 MCU 的栈空间通常仅为 8KB~64KB，远小于 PC 端 Linux 默认的 8MB 栈，轻微占用增加就可能触发溢出。
2. 动态占用不确定：中断嵌套、多任务调度、不同分支的函数调用深度差异，都会导致实际栈占用动态变化，很多溢出仅在极端边界场景下触发，开发阶段很难复现。
3. 调试信息被破坏：溢出会覆盖栈中的返回地址、LR 寄存器等关键调试信息，触发异常后调试器无法回溯调用栈，直接丢失故障现场。
4. 现象与触发点分离：溢出导致的数据污染，可能在溢出发生后很长时间才表现出异常，很难将异常现象与之前的栈操作关联起来。

三、常用栈溢出检测与防护实战

3.1 软件检测：栈填充法

栈填充法是目前开发阶段测量实际栈使用率最精确的方法，原理是在系统初始化时将整个栈空间填充为固定标记，运行一段时间后统计标记被覆盖的数量，即可得到历史最大栈使用深度。

以下是 STM32 平台的实现代码：

#include "stm32f4xx_hal.h"
#include <stdint.h>

// 链接脚本中定义的栈边界符号，不同项目符号名可能不同
extern uint32_t _estack;   // 栈底（高地址）
extern uint32_t _sstack;   // 栈顶边界（低地址）

// 选择不易被正常数据覆盖的填充模式
#define STACK_FILL_PATTERN  0xA5A5A5A5

/**
 * @brief 初始化栈填充，必须在main函数最开始调用
 */
void stack_fill_init(void)
{
    uint32_t *p_stack = (uint32_t*)&_sstack;
    uint32_t current_sp = __get_MSP();

    // 关闭中断，防止初始化过程中被打断
    uint32_t primask = __get_PRIMASK();
    __disable_irq();

    // 从栈顶边界填充到当前栈指针位置
    for(; (uint32_t)p_stack < current_sp; p_stack++)
    {
        *p_stack = STACK_FILL_PATTERN;
    }

    // 恢复中断状态
    __set_PRIMASK(primask);
}

/**
 * @brief 获取当前栈使用率，返回0~100百分比
 * @return 栈使用率百分比
 */
uint8_t stack_get_usage(void)
{
    uint32_t *p_stack = (uint32_t*)&_sstack;
    uint32_t total_size = (uint32_t)&_estack - (uint32_t)&_sstack;
    uint32_t used_size = 0;

    // 统计被覆盖的填充字节数
    while(p_stack < (uint32_t*)&_estack)
    {
        if(*p_stack == STACK_FILL_PATTERN)
        {
            break;
        }
        used_size += 4; // 32位对齐，每个单元占4字节
        p_stack++;
    }

    return (uint8_t)((used_size * 100) / total_size);
}

// 主函数调用示例
int main(void)
{
    HAL_Init();
    SystemClock_Config();

    stack_fill_init(); // 最早时机初始化栈填充

    while(1)
    {
        uint8_t usage = stack_get_usage();
        if(usage > 90) // 使用率超过90%为极度危险，触发错误处理
        {
            HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET);
            error_handler();
        }
        else if(usage > 80) // 超过80%触发警告日志
        {
            printf("Warning: Stack usage high: %d%%\r\n", usage);
        }

        HAL_Delay(1000);
    }
}

根据工程实践，若测得最大使用率超过 90%，说明已经存在溢出风险，必须立即调整栈大小或优化栈占用。

3.2 硬件防护：MPU 栈边界保护

对于带 MPU（内存保护单元）的 MCU，可通过硬件配置栈边界警戒区，溢出时立即触发 MemManage 异常，精准捕获溢出时机，避免隐性溢出。

以下是 STM32 平台的配置代码框架：

void mpu_stack_protection_init(void)
{
    MPU_Region_InitTypeDef MPU_InitStruct = {0};

    HAL_MPU_Disable();

    // 在栈顶下方配置4KB禁止访问区域作为警戒区
    MPU_InitStruct.Enable = MPU_REGION_ENABLE;
    MPU_InitStruct.BaseAddress = (uint32_t)&_sstack - 4096;
    MPU_InitStruct.Size = MPU_REGION_SIZE_4KB;
    MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;
    MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
    MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
    MPU_InitStruct.Number = MPU_REGION_NUMBER0;
    MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

    HAL_MPU_ConfigRegion(&MPU_InitStruct);
    HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);
}

// MemManage异常处理函数，溢出时直接进入这里
void MemManage_Handler(void)
{
    // 记录异常现场，便于调试定位
    uint32_t sp = __get_MSP();
    uint32_t cfsr = SCB->CFSR;
    printf("MemManage Fault! SP: 0x%08X, CFSR: 0x%08X\r\n", sp, cfsr);
    // 执行安全停机或系统复位
    error_handler();
}

四、全流程栈溢出预防规范

4.1 编码阶段常见错误与解决

常见错误	解决方法
随意定义大尺寸局部数组	超过 64 字节的局部数据一律改为 static 静态分配或全局分配，不占用栈空间
过度使用递归调用	嵌入式场景优先避免递归，必须使用时添加最大递归深度限制，静态验证栈占用
中断服务函数分配大量局部变量	中断保持极简，仅做标志设置和轻量拷贝，复杂逻辑交给主循环处理
RTOS 任务栈大小凭经验填写	使用 RTOS 自带的栈水位接口（如 FreeRTOS 的uxTaskGetStackHighWaterMark）测量，预留 20% 以上冗余

4.2 不同场景的防护策略

1. 裸机项目（主循环 + 中断）：所有代码共享一个栈，优先通过栈填充法测量极端场景下的最大栈使用，中断嵌套较多时可将中断栈独立分配，避免抢占主栈空间。
2. RTOS 多任务项目：每个任务独立分配栈，创建任务后必须测量每个任务的最大栈使用率，单个任务溢出不会影响其他任务，可在每个栈末尾添加哨兵变量做溢出检测。
3. 嵌入式 AI / 工业控制场景：大尺寸中间数据全部静态分配，递归逻辑改为迭代实现，拆解过深的函数调用链降低栈峰值占用，TFLM 等 AI 框架默认采用静态内存规划，本质就是规避栈溢出风险。

五、常见问题排查步骤

遇到疑似栈溢出问题，可按照以下步骤有序排查：

1. 梳理现象：记录异常表现、触发频率和系统状态，偶发无规律的变量篡改、跑飞大概率符合栈溢出特征。
2. 初步定位：确认当前栈空间配置，排查是否存在大局部数组、深层调用、高中断嵌套等风险点。
3. 静态分析：开启 GCC 的-fstack-usage编译选项，生成每个函数的栈占用报告，计算理论最大栈深度。
4. 动态验证：使用栈填充法模拟极端场景运行，测量实际使用率，超过 90% 即可确认风险。
5. 硬件确认：开启 MPU 保护后复现问题，若触发 MemManage 异常，可直接确认栈溢出并定位触发点。

六、实战总结

嵌入式 C 语言栈溢出的隐蔽性源于其偶发性强、现象不直观、会破坏调试上下文的特点，很多隐性问题甚至会在量产之后才暴露，带来极高的维护成本。栈溢出防护的核心思路不是出问题再排查，而是从编码、配置、测试全流程主动预防，建立多层级防护体系，才能从根源上降低风险。