前面我们解决了两个核心稳定性问题：六层架构解决代码耦合，FreeRTOS 多任务解决并发调度。但嵌入式设备真正走到量产后，还有一类问题最隐蔽、最难复现、也最容易导致批量退货：内存问题。

ESP32 系列虽然内存空间比传统 8 位 MCU 大很多，但如果不做规范化管理，依然会出现堆溢出、栈溢出、内存碎片、内存泄漏、DMA 访问越界、看门狗异常复位等问题。尤其是电池供电、长时间运行、高频率网络通信、频繁 OTA 的 IoT 设备，内存问题会随着运行时间逐渐暴露，现场排查成本极高。

本文从量产视角完整讲解 ESP32 内存管理体系：堆与栈的区别、内存碎片优化、泄漏检测、栈溢出定位、看门狗内存故障排查、DMA 与缓存一致性问题，以及可直接落地的内存防护规范。

一、ESP32 内存体系：先搞清楚哪些内存可能出问题

ESP32 的内存不是单一“RAM”概念，而是由多个内存区域组成，不同内存区域用途不同，故障表现也不同。

1. 堆内存 Heap

堆内存主要用于动态内存分配，例如 malloc()、calloc()、realloc()、pvPortMalloc()。

常见问题：

• 分配后未释放，导致内存泄漏；
• 释放后继续访问，导致野指针；
• 越界读写，破坏相邻内存块；
• 频繁分配释放，产生内存碎片；
• 大内存分配失败，导致任务异常。

2. 栈内存 Stack

栈内存由任务栈、中断栈组成，用于局部变量、函数调用、函数参数保存。

常见问题：

• 局部数组过大，导致栈溢出；
• 函数调用过深，栈空间耗尽；
• 任务栈创建过小，运行后期溢出；
• 中断栈使用不当，触发异常。

3. 静态内存 Static

静态内存包括全局变量、静态变量、常量区。

常见问题：

• 全局数组越界；
• 指针指向静态区后被误写；
• 常量字符串被修改；
• 大全局变量占用固定 RAM。

4. DMA 专用内存

ESP32 的 DMA 外设通常需要访问具备 DMA 能力的内存区域。

常见问题：

• 内存地址不支持 DMA；
• 缓存一致性未处理；
• DMA 访问越界；
• 缓冲区未对齐。

二、堆内存泄漏：设备越跑越慢的隐形杀手

1. 内存泄漏的典型表现

内存泄漏最典型的现象是：设备上电后运行正常，连续运行几小时、几天、几周后，逐渐出现：

• 网络连接失败；
• OTA 升级失败；
• 存储写入失败；
• 任务创建失败；
• malloc() 返回 NULL；
• 系统重启或看门狗复位。

2. 泄漏来源

常见泄漏点包括：

• 每次连接 WiFi 都分配内存，但断开后未释放；
• 每次上报数据都创建缓冲区，但未释放；
• 字符串拼接重复分配；
• 队列、信号量、任务创建失败后未清理；
• 第三方库内部泄漏；
• OTA 升级过程中临时缓冲区未释放。

3. 检测方法

ESP-IDF 提供堆信息查看接口：

#include "esp_heap_caps.h"

void print_heap_info(void)
{
    multi_heap_info_t info;
    heap_caps_get_info(&info, MALLOC_CAP_8BIT);

    printf("Total free: %d\n", info.total_free_bytes);
    printf("Total allocated: %d\n", info.total_allocated_bytes);
    printf("Largest free block: %d\n", info.largest_free_block);
    printf("Allocated blocks: %d\n", info.allocated_blocks);
    printf("Free blocks: %d\n", info.free_blocks);
}

量产代码中可以加入定时监控：

void srv_memory_monitor_task(void *arg)
{
    while (1) {
        print_heap_info();
        vTaskDelay(pdMS_TO_TICKS(60000));
    }
}

如果发现 total_free_bytes 持续下降，且没有恢复，说明存在内存泄漏。

4. 泄漏定位思路

定位泄漏不能靠猜，要按以下顺序排查：

1. 打印空闲内存趋势；
2. 关闭业务模块，观察内存是否恢复；
3. 重点检查 WiFi、OTA、JSON、MQTT、日志模块；
4. 检查 malloc/free 是否成对出现；
5. 检查异常分支是否遗漏释放；
6. 加入内存分配钩子，记录调用栈。

三、内存碎片：系统跑久了分配失败

1. 什么是内存碎片

频繁分配和释放不同大小的内存块后，空闲内存会被切割成很多小块。虽然总空闲内存可能还很多，但没有一块足够大的连续内存可用。

2. 碎片典型表现

Total free: 120KB
Largest free block: 8KB

总空闲内存很多，但需要 32KB 缓冲区时分配失败。

3. 碎片高发场景

• 频繁创建和释放字符串；
• 频繁 JSON 序列化和反序列化；
• 网络数据包频繁分包组包；
• 日志缓冲区动态分配；
• OTA 临时缓冲区反复申请释放；
• 任务栈、队列、信号量反复创建删除。

4. 优化方案

方案1：减少动态分配

优先使用静态缓冲区：

static uint8_t g_ota_buf[4096];

方案2：统一固定大小内存池

对于频繁申请释放的场景，使用固定大小内存池。

#define MEM_POOL_SIZE 16
#define MEM_BLOCK_SIZE 256

static uint8_t g_mem_pool[MEM_POOL_SIZE][MEM_BLOCK_SIZE];
static bool g_mem_used[MEM_POOL_SIZE];

void *mem_pool_alloc(void)
{
    for (int i = 0; i < MEM_POOL_SIZE; i++) {
        if (!g_mem_used[i]) {
            g_mem_used[i] = true;
            return g_mem_pool[i];
        }
    }
    return NULL;
}

void mem_pool_free(void *ptr)
{
    for (int i = 0; i < MEM_POOL_SIZE; i++) {
        if (ptr >= g_mem_pool[0] && ptr < g_mem_pool[MEM_POOL_SIZE]) {
            int idx = ((uint8_t *)ptr - g_mem_pool[0]) / MEM_BLOCK_SIZE;
            g_mem_used[idx] = false;
            return;
        }
    }
}

方案3：大缓冲区生命周期拉长

OTA、日志、JSON 解析等大缓冲区，不要每次临时分配，而是在模块初始化时一次申请，模块销毁时统一释放。

方案4：避免小粒度频繁分配

不要在循环中反复分配小块内存，尽量复用缓冲区。

四、栈溢出：最常见的任务死机原因

1. 栈溢出的典型表现

栈溢出通常表现为：

• 任务莫名崩溃；
• 函数返回地址被破坏；
• 局部变量值异常；
• 系统复位；
• 看门狗复位；
• 中断异常。

2. 栈溢出原因

最常见原因是任务栈创建过小：

// 风险示例
xTaskCreate(app_task, "app_task", 2048, NULL, 5, NULL);

如果任务内部有大数组、深层函数调用、复杂业务逻辑，2KB 栈很容易溢出。

另一个常见原因是局部数组过大：

void app_handle_data(void)
{
    uint8_t buf[2048];
}

这个数组会直接压入栈，很容易耗尽任务栈。

3. 栈溢出检测

ESP-IDF 可以开启栈溢出检测：

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

void check_task_stack(const char *task_name, TaskHandle_t task)
{
    UBaseType_t high_water = uxTaskGetStackHighWaterMark(task);
    printf("Task %s stack high water: %u words\n", task_name, high_water);
}

high_water 表示历史剩余栈空间，单位为 words。

如果值接近 0，说明栈空间严重不足。

4. 栈溢出优化方案

方案1：增大任务栈

xTaskCreate(app_task, "app_task", 8192, NULL, 5, NULL);

方案2：大数组改为静态或全局

static uint8_t g_app_buf[2048];

方案3：减少函数调用深度

避免任务函数层层嵌套。

方案4：局部变量减少

把不需要临时保存的变量改为静态变量。

五、堆溢出与野指针：最难排查的内存 corruption

1. 堆溢出表现

堆溢出通常会破坏堆管理结构，导致后续 malloc()、free() 异常。

典型日志：

assert failed: heap_caps_free heap_caps.c:240

或者：

corrupted block

2. 常见原因

uint8_t *buf = malloc(16);
buf[16] = 0xFF;

分配 16 字节，但写入第 17 字节，越界破坏堆结构。

另一种是野指针：

uint8_t *buf = malloc(16);
free(buf);
buf[0] = 0xFF;

释放后继续访问。

3. 排查方法

开启堆检查：

heap_caps_check_integrity_all(true);

发现堆结构异常时，立即打印错误。

量产代码中可以在关键节点加入检查：

if (!heap_caps_check_integrity_all(true)) {
    printf("Heap corrupted!\n");
    print_heap_info();
}

六、DMA 内存与缓存一致性问题

ESP32 的 DMA 访问内存时，需要注意内存是否具备 DMA 能力，以及缓存一致性。

1. DMA 内存要求

部分内存地址不支持 DMA，如果直接使用，可能导致传输失败或数据异常。

正确做法是使用 DMA 能力标志分配内存：

uint8_t *buf = heap_caps_malloc(4096, MALLOC_CAP_DMA);
if (buf == NULL) {
    printf("DMA buffer alloc failed\n");
}

2. 缓存一致性问题

ESP32 数据缓存可能导致 CPU 写入的数据和 DMA 看到的数据不一致。

如果 CPU 修改了 DMA 缓冲区，需要刷缓存：

esp_cache_sync(buf, 4096);

如果 DMA 完成后 CPU 要读取数据，也需要使缓存失效：

esp_cache_invalidate(buf, 4096);

七、看门狗内存故障定位流程

很多时候系统复位不是单纯看门狗超时，而是内存问题间接导致任务卡死、中断异常、看门狗触发。

1. 内存故障排查顺序

系统复位
  ↓
查看复位原因
  ↓
查看任务栈水位
  ↓
查看堆空闲趋势
  ↓
检查 malloc/free 配对
  ↓
检查数组越界
  ↓
检查 DMA 缓冲区
  ↓
检查中断栈和任务栈
  ↓
加入内存监控日志

2. 复位原因读取

#include "esp_system.h"

void print_reset_reason(void)
{
    esp_reset_reason_t reason = esp_reset_reason();
    printf("Reset reason: %d\n", reason);

    switch (reason) {
        case ESP_RST_POWERON:
            printf("Power on reset\n");
            break;
        case ESP_RST_EXT:
            printf("External pin reset\n");
            break;
        case ESP_RST_SW:
            printf("Software reset\n");
            break;
        case ESP_RST_PANIC:
            printf("Panic reset\n");
            break;
        case ESP_RST_WDT:
            printf("Watchdog reset\n");
            break;
        default:
            printf("Unknown reset reason\n");
            break;
    }
}

3. 看门狗复位后的内存排查重点

如果复位原因是 ESP_RST_WDT，重点排查：

• 高优先级任务长时间阻塞；
• 喂狗任务被低优先级任务饿死；
• 中断服务程序过长；
• 任务死循环；
• 堆 corruption 导致任务异常；
• 栈溢出导致程序跑飞；
• DMA 或缓存一致性异常导致外设死锁。
  

八、量产内存防护规范

1. 内存分配规范

• 模块初始化时一次分配，退出时统一释放；
• 禁止循环中频繁分配释放；
• 大缓冲区优先静态化；
• 小内存频繁申请使用固定内存池；
• 每次 malloc() 后必须检查返回值。

2. 栈使用规范

• 任务栈按实际需求预留 20%~50% 余量；
• 禁止在任务栈中定义大数组；
• 函数调用深度控制在合理范围；
• 定期打印任务栈水位。

3. 数组规范

• 数组访问必须带边界判断；
• 字符串操作使用安全函数；
• 固定长度协议字段使用宏定义；
• 全局数组优先使用 static const 或静态缓冲区。

4. DMA 规范

• DMA 缓冲区使用 MALLOC_CAP_DMA；
• DMA 缓冲区地址对齐；
• 传输前后处理缓存一致性；
• DMA 完成后检查传输状态。

5. 监控规范

• 定时打印堆信息；
• 定时检查任务栈水位；
• 关键路径加入堆完整性检查；
• 异常复位前保存内存快照；
• 量产日志记录最小空闲内存、最大连续空闲块、复位原因。

九、总结

ESP32 内存问题不是单纯“内存不够”，而是一个系统性问题：

• 堆泄漏导致设备越跑越慢；
• 内存碎片导致大缓冲区分配失败；
• 栈溢出导致任务崩溃；
• 堆溢出导致系统 corruption；
• DMA 与缓存一致性导致外设异常；
• 内存问题最终可能表现为看门狗复位。

量产项目不能只靠“加大内存、加大栈”解决问题，必须建立规范：静态缓冲区优先、动态分配可控、内存池复用、监控日志完整、异常可定位。

下一篇预告：《看门狗全解析：ESP32-P4 HP_SYS_WDT 复位完整排查流程》，聚焦看门狗复位的真实排查路径，包括喂狗机制、超时判定、任务饿死、中断喂狗、内核异常、复位日志和量产兜底方案。