多个小应用共用一块 ESP32 Flash这问题我在不少项目里都踩过。最开始做一个内嵌Web配置页 传感器日志 OTA升级 蓝牙配网的全能小设备时天真地以为程序里各管各的变量就能把数据分开结果固件升级一次配置文件没了日志写多了Web页面又打不开更诡异的是NVS里的配网信息偶尔会被一遍遍覆盖整个设备必须重新配网。排查到最后根子都在同一个地方大家共用一块Flash却没有给数据划清地盘。这篇就聊聊我在这类一芯多应用场景下的Flash分区和隔离经验。核心思路一句话想让数据不串门靠代码里躲是躲不过去的必须从Flash底层的分区设计做起再配合应用层的命名空间和文件系统隔离。这整套东西适合正在做ESP32多功能设备、想搞懂分区表机制、以及被OTA和文件系统存储问题折磨过的开发者看。1. 为什么共用一块Flash必然会出问题1.1 多个小应用的真实存储场景先盘点一下一个ESP32设备上到底有哪几类东西在抢Flash。最常见的是这五类固件本身App编译出来的bin文件可能一个也可能两个OTA双备份。Web前端资源用ESP32内置Web服务器时HTML、CSS、JS、图片一般打包进SPIFFS或LittleFS文件系统分区。配置参数WiFi账号密码、设备编号、校准系数这类键值对通常放NVSNon-Volatile Storage非易失性存储。运行日志和数据采集结果传感器历史记录、错误日志也是放文件系统分区或者专门的日志分区。蓝牙配网、终端调试等临时数据有时候也会想存下来比如蓝牙配网时缓存中间状态。一台设备同时干这么多事太正常了。网上随便搜esp32内嵌web网页esp32 蓝牙教程esp32项目esp32 温湿度传感器使用这些词出来的方案基本都是这几个功能叠加的组合体。1.2 数据串门到底是怎么发生的不做隔离的时候所有应用都往同一个Flash地址空间里写就会出下面这些乱子覆盖式串门A应用以为自己在存配置实际写入的地址段正好是B应用的固件区域一次写入直接让固件崩溃。这个最致命而且很难复现因为地址都是算出来的差一个字节都不行。擦除式串门Flash写入前必须擦除而擦除的最小单位是扇区常见4KB。如果一个应用把某个扇区擦掉了恰好另一个应用的数据也在这个扇区里两边一起遭殃。增长式串门日志类数据是往后追加写的越写越长今天没问题跑三天后溢出了把邻接区域冲垮。很多用着用着突然变砖的设备都是这个原因。OTA式串门OTA升级时新固件要写到另一个分区如果分区规划不合理新固件长度超过分区大小直接覆盖到隔壁文件系统分区升级完数据全没了。这些现象表面看是程序bug本质上是存储布局没有设计。就像一栋楼里住好几户每户房间多大、走哪个门必须有清晰的户型图。没有户型图就装修谁先开工谁占地方后面的人只能挤。2. 分区表给Flash划好房间2.1 分区表长什么样ESP32的分区表本质是放在Flash固定位置默认0x9000偏移的一张清单里面对每一块Flash区域定义好名字、类型、子类型、偏移、大小。烧录时bootloader会读这张表系统运行时也是靠它来定位我要找的数据在哪。我最早一直以为分区表是固定的后来才发现它完全可以让用户自定义。官方工具链里用的是CSV文本编译时会生成bin再烧到Flash里。一份最简单的CSV长这样# ESP-IDF Partition Table # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x200000,看到没有这就是户型图。有了它bootloader就知道第一户nvs分区从0x9000开始占24KB第二户phy_init接着往后固件从0x10000开始占2MB。2.2 字段逐个拆解每个字段都是有讲究的我踩过坑之后才真正搞明白Name就是给分区起名字代码里要用这个名字来查找分区。比如partition esp_partition_find_first(ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, storage)这里storage就是CSV里定义的名字。名字可以随便起但最好见名知义。Type和SubType这是整个分区表最关键的设计。Type分两大类app和data。app是固件data是数据。SubType进一步细分app有factory、ota_0、ota_1等data有nvs、phy、spiffs、fat等。类型的作用是让ESP-IDF的API能区分和处理不同分区也决定了部分分区的默认行为。Offset分区的起始地址。注意几点第一个分区通常从0x9000开始0x1000到0x8000是bootloader区域0x8000到0x9000是分区表本身。后续分区的offset不写的话留空工具会自动接着上一个分区末尾继续排。但要小心自动排和手动排混用容易出问题。Offset有对齐要求app分区必须按0x1000064KB对齐大部分时候为了省心所有分区都按0x10000对齐。Size这个不用多说唯一要提醒的是别只算当下。日志分区要给余量OTA分区要够容纳固件的最大膨胀版本NVS分区太小会导致键写不进去。2.3 常用分区类型的功能定位我整理了一张常用分区类型的对照表做方案时直接对着选分区TypeSubType典型用途备注appfactory出厂固件没有OTA时用这个appota_0 / ota_1OTA双备份固件必须有otadata分区配合apptest工厂测试固件一般不常用datanvs键值对存储WiFi配置等有专门API注意大小dataotadataOTA状态记录OTA方案必配很小dataphy_initWiFi/BT校准数据默认保留即可dataspiffs / littlefs文件系统Web页面、日志数据datacoredump崩溃日志调试神器注意nvs和otadata都有只能有一个的约束使用特殊key的情况除外ota_0和ota_1必须成对出现。这些细节都是在规划阶段必须确认的否则编译报错或者运行时行为异常。3. 实操给一芯多应用设计一份可靠的分区方案3.1 先盘点需求再动手做分区规划我推荐先拿一张纸把设备所有功能列出来再对应到存储需求不要上来就抄模板。我自己做的一个典型设备是这样盘点的固件区主固件基于ESP-IDF开发编译后约800KB考虑到以后加功能至少留1MB。要做OTA就得两份ota_0和ota_1各1MB。文件系统Web管理页面HTML/CSS/JS约300KB运行日志和传感器数据预留空间合计1MB比较稳妥。NVS用来存WiFi账号、设备参数、校准数据默认20KB够用但考虑到蓝牙配网的中间状态我留了24KB或32KB更安心。调试辅助coredump日志不常开但线上问题排查非常有用我给它32KB。phy_init默认即可4KB。盘完之后发现4MB的Flash如果不仔细规划很可能捉襟见肘。尤其是一块4MB的Flashbootloader加分区表去掉约36KB实际可用大约4036KB。3.2 分区表CSV实例与参数计算我最后用的CSV长这样# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x100000, otadata, data, ota, 0x110000, 0x2000, ota_0, app, ota_0, 0x120000, 0x100000, ota_1, app, ota_1, 0x220000, 0x100000, coredump, data, coredump,0x320000, 0x8000, storage, data, spiffs, 0x328000, 0xC8000,这里的参数我是这么计算的nvs大小0x600024KBESP32的NVS页大小是4KB24KB能容纳很多键且留有余量。我之前用过默认16KB结果键一多就返回ESP_ERR_NVS_NOT_ENOUGH_SPACE。factory分区0x1000001MB当前固件800KB留200KB冗余。注意app分区起始偏移0x10000这是align到64KB的。otadata 0x20008KB足够存放OTA状态官方默认也差不多。ota_0和ota_1各1MB这两个分区必须大小一致且对齐才能保证OTA后新旧固件可以互相覆盖而不越界。coredump 32KB崩溃时的RAM镜像32KB够大部分场景。storage 0xC8000800KBWeb页面300KB 日志预留500KB。这里我特意算过日志轮转保留最近7天每天约60KB500KB刚好。有个容易被忽略的点所有尺寸单位在CSV里可以是K或M但我习惯直接用十六进制字节避免误读。另外工具链对分区大小有对齐要求如果某个值不对编译时会直接报错不会给你含糊的空间。3.3 烧录与验证分区方案分区表CSV写好后编译时ESP-IDF或Arduino环境会自动生成partition table bin。但如果你是用自定义CSV一定要确认构建系统真的用了你的文件。在ESP-IDF里需要配置idf.py menuconfig # 进入 Partition Table - Custom partition table CSV # 填入自定义CSV路径烧录时分区表必须和固件一起烧idf.py -p /dev/ttyUSB0 flash如果想单独验证烧进去的分区表有没有生效强烈推荐用读回的方式确认esptool.py --port /dev/ttyUSB0 read_flash 0x9000 0x3000 partition_table.bin再用ESP-IDF自带的工具解析一下内容看打印出来的表是不是自己设计的那份。这一步虽然多花两分钟但能在项目一开始就拦住分区表没烧进去这类极其隐蔽的问题。我在Arduino环境下也反复确认过用Arduino IDE时工具链默认用内置分区方案自定义方案必须修改board配置里的Partition Scheme或者在platformio.ini里指定board_build.partitions partitions.csv。4. 代码里的数据隔离不只靠分区分区表划完只是房间分好了。住在不同房间里的应用还得有自己独立的门锁和钥匙。这一层应用侧的隔离做不好照样能串门。4.1 NVS键值对的命名空间隔离NVS本身就是一个键值数据库很多人以为有键名就够了其实NVS还有个命名空间namespace的概念。两个不同的namespace即使键名相同值也互不可见。这是多个小应用共享NVS时的第一道隔离墙。我的做法是给每个小应用分配独立的namespace// 配置类应用使用 config_ns esp_err_t err nvs_open(config_ns, NVS_READWRITE, handle_cfg); nvs_set_str(handle_cfg, wifi_ssid, ssid); nvs_set_str(handle_cfg, wifi_pwd, password); // 日志类应用使用 log_ns esp_err_t err2 nvs_open(log_ns, NVS_READWRITE, handle_log); nvs_set_u32(handle_log, last_boot, timestamp);这样即使两个namespace里都有last_boot这个键读出来也各是各的不会混淆。还有一个细节NVS在断电瞬间写入容易出现损坏损坏后NVS会尝试用备份页恢复。如果两个应用同时频繁写NVS冲突概率会上升。所以我在实际项目里还会做写操作互斥用nvs_set_*后立刻nvs_commit并且建议多个小应用不要都直接高频写NVS日志类数据尽量走文件系统NVS只存配置和状态。4.2 文件系统分区挂载一份数据一个盘如果两个小应用都用SPIFFS/LittleFS但共用同一个文件系统分区那串门依然存在A应用删文件B应用的文件也不见了A应用写满B应用就没空间了。真正的隔离是给它们分配不同的文件系统分区然后分别挂载。在程序里这样挂载// 挂载Web资源分区 esp_vfs_spiffs_conf_t web_conf { .base_path /web, .partition_label webui, .max_files 5, .format_if_mount_failed false, }; esp_vfs_spiffs_register(web_conf); // 挂载日志分区 esp_vfs_spiffs_conf_t log_conf { .base_path /log, .partition_label logdata, .max_files 5, .format_if_mount_failed false, }; esp_vfs_spiffs_register(log_conf);注意这里每个partition_label对应CSV里不同的分区名。挂在/web下的文件和挂在/log下的文件从文件系统层面就完全隔离了。A应用的代码去/web写东西永远不会碰到/log里的日志。还有一点容易踩坑format_if_mount_failed这个参数。如果设为true一旦文件系统挂载失败比如被异常数据破坏了系统会自动格式化这倒是省心但会把该分区所有数据全清掉。对存储重要日志的分区我会设成false即使挂载失败也要先保住数据再说。4.3 分区标签在代码中的准确引用前面提到代码里用partition_label但在ESP-IDF的API里找分区更常用的方式是通过类型和子类型。很多初学者在这一步会把分区名和子类型搞混。比如const esp_partition_t* part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, storage); if (part NULL) { ESP_LOGE(TAG, partition storage not found); return; }第三个参数是CSV里的Name而前面两个是Type和SubType。如果我CSV里叫storage代码里写webui就找不到。这种错误编译期查不出来运行时才报错排查时先核对名字拼写。4.4 OTA升级时的分区切换与数据保护OTA场景下串门还有一层特殊含义新固件可能和旧固件读写不同的分区。如果旧固件用的是factory分区新固件OTA到了ota_0分区两者虽然代码逻辑一样但跑起来后对NVS和文件系统分区的访问应该是一致的。OTA本身依赖otadata分区记录当前应该从哪个分区启动。升级流程大致是下载新固件写入ota_1分区假设当前从ota_0启动。写入完成后设置otadata为下次从ota_1启动。重启bootloader读取otadata从ota_1启动。新固件自检通过后把otadata标记为确认可用如果不通过回滚到ota_0。这里面最容易出问题的是分区大小和固件大小不匹配。我遇到过固件在开发期不断膨胀某次OTA后写入失败原因是目标分区大小不够。排查时看见esp_ota_ops.c报ESP_ERR_FLASH_SIZE_NOT_MATCH这才意识到是分区规划时的余量给少了。从此之后我在规划OTA分区时有一个习惯把分区大小设为当前固件体积的1.5倍或至少多留300KB。另外如果多个小应用都在做OTA一定要明确只有一个OTA主流程不能让两个应用同时操作otadata和ota_0/ota_1分区。我见过一个设备主控逻辑和蓝牙模块都尝试触发OTA结果两个写并发把otadata写坏系统反复重启也起不来。后来的处理是在OTA入口加互斥锁并且由统一的任务管理。5. 常见问题与排查技巧实录5.1 分区表没有生效这个问题我遇到太多次了典型现象是代码里明明能找到的分区运行时报错找不到或者明明CSV里定义了很大空间实际写文件写到一半就满了。排查思路按顺序来确认烧录时确实烧了新的分区表。用esptool.py read_flash读回0x9000处的内容和本地生成的partition table bin对比。很多分区没生效其实是烧录时分区表没更新固件倒是新的分区表还是旧的。确认用的是自定义CSV。ESP-IDF默认会用内置的分区方案Arduino环境更明显需要手动选择分区方案。在PlatformIO里我会在platformio.ini里写死board_build.partitions partitions.csv避免IDE设置被无意改动。确认CSV语法和内容没有逻辑冲突。比如NVS分区和otadata分区出现多个、app分区没有按64KB对齐、分区之间重叠特别是手动指定offset时这些CSV工具会报错但有些看起来合法的重叠比如size写过了边界工具未必能发现。我自己还踩过一次特别隐蔽的坑用文本编辑器在CSV里加了带BOM的UTF-8头工具链解析第一个字段时带了隐藏字符导致找不到分区。排查了很久最后用xxd看文件头才发现。5.2 数据串门的典型症状遇到下面这些情况优先怀疑Flash隔离方案有问题症状可能原因排查方向升级固件后WiFi配置丢失NVS被擦除或NVS分区被覆盖检查是否有代码调nvs_flash_erase检查OTA写越界写日志后Web页面文件损坏日志分区和Web分区在同一文件系统拆分文件系统分区或检查文件系统分区Size溢出设备运行几天后崩溃重启日志区写满后覆盖邻接分区增加日志轮转或单独给日志分配分区OTA升级后启动异常ota分区大小不足或otadata损坏检查分区表里ota_0/ota_1大小调整otadataNVS写入返回ESP_ERR_NVS_NOT_ENOUGH_SPACENVS分区过小或namespace过多扩大NVS分区或减少存储键其中一个我印象最深的问题是设备里一个任务是采集温湿度并写日志另一个任务是Web服务器。两者共用SPIFFS分区一开始都正常但采集任务每5分钟写一条日志几天后Web页面所有图片全打不开了。表面看是图片损坏实际是日志把分区写满文件系统碎片化严重导致原先可以读取的文件被挤到不可用区域。后来把日志独立到专门分区Web页面设置format_if_mount_failedfalse且禁止日志任务跨分区访问问题彻底消失。5.3 避坑清单结合这些年的项目经验整理一份我每次做ESP32存储方案都会过一遍的清单先画分区图再写代码。任何存数据的功能动手前先明确写在哪个分区、用什么API。没有明确存储归属的功能默认不实现。减小NVS写入频率。NVS按扇区擦写频繁写入会加速Flash磨损。日志、采集数据不要用NVS用文件系统。OTA分区要比实际固件大出足够余量。建议至少1.3倍至1.5倍。每次固件体积大幅增加后回头检查分区大小是否仍够。文件系统挂载失败策略要分场景。可再生的缓存数据可以格式化珍贵日志和用户配置绝对不能自动格式化。用分区标签partition_label而不是硬编码地址。代码里用硬编码地址一旦分区表调整就全盘崩盘用API查表找分区是正道。日志和业务数据尽量分应用独立目录即使在同一文件系统分区也通过子目录约束方便误删时止损。定期做掉电测试。数据隔离方案是否可靠不能只在常温常态下验要做随机断电写入测试。ESP32在写入中途断电最容易暴露Flash隔离设计的漏洞。5.4 应急恢复数据已经被串门了怎么办最后这条是给已经出问题的朋友看的。当你发现设备数据已经被写坏先别急着格式化重来。如果只是某个分区的数据损坏可以先尝试只擦除那个分区esptool.py --port /dev/ttyUSB0 erase_region 0x328000 0xC8000这样可以保住其他分区的数据。如果整个Flash乱成一团且固件还能正常跑可以先导出NVS里还有的配置nvs_handle_t handle; nvs_open(config_ns, NVS_READONLY, handle); char ssid[32]; size_t len sizeof(ssid); if (nvs_get_str(handle, wifi_ssid, ssid, len) ESP_OK) { // 写回电脑或备份 }数据备份这个习惯真的很重要。我后来在所有项目的NVS写入流程里都加了一个配置版本号键每次写入配置时版本号加1。一旦出现异常至少能知道配置是什么时候被改的排查范围一下子缩小很多。关于现网设备的远程数据恢复还有一个技巧利用OTA流程里的esp_ota_get_running_partition区分当前固件再结合分区表做定向恢复。但这个方法需要提前在固件里预留恢复逻辑属于平时不用、关键时救命的设计值得在架构规划时就埋进去。我个人在实际操作中的体会是Flash隔离这件事越早做成本越低。等代码写了几万行再回来调整分区表等于给一栋已经住满人的楼重新改户型牵一发动全身。新项目开始的那天花半小时画一张分区图后面能省下几天甚至几周的排查时间。另外多说一句分区方案不是一劳永逸的固件体积、日志策略、功能数量都会变每次版本迭代都回头瞄一眼分区表这个习惯帮我避开了不少线上事故。 
长河君 · 2026/10/31 1:06:50 · 阅读 1.2k ESP32 Flash分区与隔离实战：一芯多应用如何避免数据串门
多个小应用共用一块 ESP32 Flash这问题我在不少项目里都踩过。最开始做一个内嵌Web配置页 传感器日志 OTA升级 蓝牙配网的全能小设备时天真地以为程序里各管各的变量就能把数据分开结果固件升级一次配置文件没了日志写多了Web页面又打不开更诡异的是NVS里的配网信息偶尔会被一遍遍覆盖整个设备必须重新配网。排查到最后根子都在同一个地方大家共用一块Flash却没有给数据划清地盘。这篇就聊聊我在这类一芯多应用场景下的Flash分区和隔离经验。核心思路一句话想让数据不串门靠代码里躲是躲不过去的必须从Flash底层的分区设计做起再配合应用层的命名空间和文件系统隔离。这整套东西适合正在做ESP32多功能设备、想搞懂分区表机制、以及被OTA和文件系统存储问题折磨过的开发者看。1. 为什么共用一块Flash必然会出问题1.1 多个小应用的真实存储场景先盘点一下一个ESP32设备上到底有哪几类东西在抢Flash。最常见的是这五类固件本身App编译出来的bin文件可能一个也可能两个OTA双备份。Web前端资源用ESP32内置Web服务器时HTML、CSS、JS、图片一般打包进SPIFFS或LittleFS文件系统分区。配置参数WiFi账号密码、设备编号、校准系数这类键值对通常放NVSNon-Volatile Storage非易失性存储。运行日志和数据采集结果传感器历史记录、错误日志也是放文件系统分区或者专门的日志分区。蓝牙配网、终端调试等临时数据有时候也会想存下来比如蓝牙配网时缓存中间状态。一台设备同时干这么多事太正常了。网上随便搜esp32内嵌web网页esp32 蓝牙教程esp32项目esp32 温湿度传感器使用这些词出来的方案基本都是这几个功能叠加的组合体。1.2 数据串门到底是怎么发生的不做隔离的时候所有应用都往同一个Flash地址空间里写就会出下面这些乱子覆盖式串门A应用以为自己在存配置实际写入的地址段正好是B应用的固件区域一次写入直接让固件崩溃。这个最致命而且很难复现因为地址都是算出来的差一个字节都不行。擦除式串门Flash写入前必须擦除而擦除的最小单位是扇区常见4KB。如果一个应用把某个扇区擦掉了恰好另一个应用的数据也在这个扇区里两边一起遭殃。增长式串门日志类数据是往后追加写的越写越长今天没问题跑三天后溢出了把邻接区域冲垮。很多用着用着突然变砖的设备都是这个原因。OTA式串门OTA升级时新固件要写到另一个分区如果分区规划不合理新固件长度超过分区大小直接覆盖到隔壁文件系统分区升级完数据全没了。这些现象表面看是程序bug本质上是存储布局没有设计。就像一栋楼里住好几户每户房间多大、走哪个门必须有清晰的户型图。没有户型图就装修谁先开工谁占地方后面的人只能挤。2. 分区表给Flash划好房间2.1 分区表长什么样ESP32的分区表本质是放在Flash固定位置默认0x9000偏移的一张清单里面对每一块Flash区域定义好名字、类型、子类型、偏移、大小。烧录时bootloader会读这张表系统运行时也是靠它来定位我要找的数据在哪。我最早一直以为分区表是固定的后来才发现它完全可以让用户自定义。官方工具链里用的是CSV文本编译时会生成bin再烧到Flash里。一份最简单的CSV长这样# ESP-IDF Partition Table # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x200000,看到没有这就是户型图。有了它bootloader就知道第一户nvs分区从0x9000开始占24KB第二户phy_init接着往后固件从0x10000开始占2MB。2.2 字段逐个拆解每个字段都是有讲究的我踩过坑之后才真正搞明白Name就是给分区起名字代码里要用这个名字来查找分区。比如partition esp_partition_find_first(ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, storage)这里storage就是CSV里定义的名字。名字可以随便起但最好见名知义。Type和SubType这是整个分区表最关键的设计。Type分两大类app和data。app是固件data是数据。SubType进一步细分app有factory、ota_0、ota_1等data有nvs、phy、spiffs、fat等。类型的作用是让ESP-IDF的API能区分和处理不同分区也决定了部分分区的默认行为。Offset分区的起始地址。注意几点第一个分区通常从0x9000开始0x1000到0x8000是bootloader区域0x8000到0x9000是分区表本身。后续分区的offset不写的话留空工具会自动接着上一个分区末尾继续排。但要小心自动排和手动排混用容易出问题。Offset有对齐要求app分区必须按0x1000064KB对齐大部分时候为了省心所有分区都按0x10000对齐。Size这个不用多说唯一要提醒的是别只算当下。日志分区要给余量OTA分区要够容纳固件的最大膨胀版本NVS分区太小会导致键写不进去。2.3 常用分区类型的功能定位我整理了一张常用分区类型的对照表做方案时直接对着选分区TypeSubType典型用途备注appfactory出厂固件没有OTA时用这个appota_0 / ota_1OTA双备份固件必须有otadata分区配合apptest工厂测试固件一般不常用datanvs键值对存储WiFi配置等有专门API注意大小dataotadataOTA状态记录OTA方案必配很小dataphy_initWiFi/BT校准数据默认保留即可dataspiffs / littlefs文件系统Web页面、日志数据datacoredump崩溃日志调试神器注意nvs和otadata都有只能有一个的约束使用特殊key的情况除外ota_0和ota_1必须成对出现。这些细节都是在规划阶段必须确认的否则编译报错或者运行时行为异常。3. 实操给一芯多应用设计一份可靠的分区方案3.1 先盘点需求再动手做分区规划我推荐先拿一张纸把设备所有功能列出来再对应到存储需求不要上来就抄模板。我自己做的一个典型设备是这样盘点的固件区主固件基于ESP-IDF开发编译后约800KB考虑到以后加功能至少留1MB。要做OTA就得两份ota_0和ota_1各1MB。文件系统Web管理页面HTML/CSS/JS约300KB运行日志和传感器数据预留空间合计1MB比较稳妥。NVS用来存WiFi账号、设备参数、校准数据默认20KB够用但考虑到蓝牙配网的中间状态我留了24KB或32KB更安心。调试辅助coredump日志不常开但线上问题排查非常有用我给它32KB。phy_init默认即可4KB。盘完之后发现4MB的Flash如果不仔细规划很可能捉襟见肘。尤其是一块4MB的Flashbootloader加分区表去掉约36KB实际可用大约4036KB。3.2 分区表CSV实例与参数计算我最后用的CSV长这样# Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x100000, otadata, data, ota, 0x110000, 0x2000, ota_0, app, ota_0, 0x120000, 0x100000, ota_1, app, ota_1, 0x220000, 0x100000, coredump, data, coredump,0x320000, 0x8000, storage, data, spiffs, 0x328000, 0xC8000,这里的参数我是这么计算的nvs大小0x600024KBESP32的NVS页大小是4KB24KB能容纳很多键且留有余量。我之前用过默认16KB结果键一多就返回ESP_ERR_NVS_NOT_ENOUGH_SPACE。factory分区0x1000001MB当前固件800KB留200KB冗余。注意app分区起始偏移0x10000这是align到64KB的。otadata 0x20008KB足够存放OTA状态官方默认也差不多。ota_0和ota_1各1MB这两个分区必须大小一致且对齐才能保证OTA后新旧固件可以互相覆盖而不越界。coredump 32KB崩溃时的RAM镜像32KB够大部分场景。storage 0xC8000800KBWeb页面300KB 日志预留500KB。这里我特意算过日志轮转保留最近7天每天约60KB500KB刚好。有个容易被忽略的点所有尺寸单位在CSV里可以是K或M但我习惯直接用十六进制字节避免误读。另外工具链对分区大小有对齐要求如果某个值不对编译时会直接报错不会给你含糊的空间。3.3 烧录与验证分区方案分区表CSV写好后编译时ESP-IDF或Arduino环境会自动生成partition table bin。但如果你是用自定义CSV一定要确认构建系统真的用了你的文件。在ESP-IDF里需要配置idf.py menuconfig # 进入 Partition Table - Custom partition table CSV # 填入自定义CSV路径烧录时分区表必须和固件一起烧idf.py -p /dev/ttyUSB0 flash如果想单独验证烧进去的分区表有没有生效强烈推荐用读回的方式确认esptool.py --port /dev/ttyUSB0 read_flash 0x9000 0x3000 partition_table.bin再用ESP-IDF自带的工具解析一下内容看打印出来的表是不是自己设计的那份。这一步虽然多花两分钟但能在项目一开始就拦住分区表没烧进去这类极其隐蔽的问题。我在Arduino环境下也反复确认过用Arduino IDE时工具链默认用内置分区方案自定义方案必须修改board配置里的Partition Scheme或者在platformio.ini里指定board_build.partitions partitions.csv。4. 代码里的数据隔离不只靠分区分区表划完只是房间分好了。住在不同房间里的应用还得有自己独立的门锁和钥匙。这一层应用侧的隔离做不好照样能串门。4.1 NVS键值对的命名空间隔离NVS本身就是一个键值数据库很多人以为有键名就够了其实NVS还有个命名空间namespace的概念。两个不同的namespace即使键名相同值也互不可见。这是多个小应用共享NVS时的第一道隔离墙。我的做法是给每个小应用分配独立的namespace// 配置类应用使用 config_ns esp_err_t err nvs_open(config_ns, NVS_READWRITE, handle_cfg); nvs_set_str(handle_cfg, wifi_ssid, ssid); nvs_set_str(handle_cfg, wifi_pwd, password); // 日志类应用使用 log_ns esp_err_t err2 nvs_open(log_ns, NVS_READWRITE, handle_log); nvs_set_u32(handle_log, last_boot, timestamp);这样即使两个namespace里都有last_boot这个键读出来也各是各的不会混淆。还有一个细节NVS在断电瞬间写入容易出现损坏损坏后NVS会尝试用备份页恢复。如果两个应用同时频繁写NVS冲突概率会上升。所以我在实际项目里还会做写操作互斥用nvs_set_*后立刻nvs_commit并且建议多个小应用不要都直接高频写NVS日志类数据尽量走文件系统NVS只存配置和状态。4.2 文件系统分区挂载一份数据一个盘如果两个小应用都用SPIFFS/LittleFS但共用同一个文件系统分区那串门依然存在A应用删文件B应用的文件也不见了A应用写满B应用就没空间了。真正的隔离是给它们分配不同的文件系统分区然后分别挂载。在程序里这样挂载// 挂载Web资源分区 esp_vfs_spiffs_conf_t web_conf { .base_path /web, .partition_label webui, .max_files 5, .format_if_mount_failed false, }; esp_vfs_spiffs_register(web_conf); // 挂载日志分区 esp_vfs_spiffs_conf_t log_conf { .base_path /log, .partition_label logdata, .max_files 5, .format_if_mount_failed false, }; esp_vfs_spiffs_register(log_conf);注意这里每个partition_label对应CSV里不同的分区名。挂在/web下的文件和挂在/log下的文件从文件系统层面就完全隔离了。A应用的代码去/web写东西永远不会碰到/log里的日志。还有一点容易踩坑format_if_mount_failed这个参数。如果设为true一旦文件系统挂载失败比如被异常数据破坏了系统会自动格式化这倒是省心但会把该分区所有数据全清掉。对存储重要日志的分区我会设成false即使挂载失败也要先保住数据再说。4.3 分区标签在代码中的准确引用前面提到代码里用partition_label但在ESP-IDF的API里找分区更常用的方式是通过类型和子类型。很多初学者在这一步会把分区名和子类型搞混。比如const esp_partition_t* part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, storage); if (part NULL) { ESP_LOGE(TAG, partition storage not found); return; }第三个参数是CSV里的Name而前面两个是Type和SubType。如果我CSV里叫storage代码里写webui就找不到。这种错误编译期查不出来运行时才报错排查时先核对名字拼写。4.4 OTA升级时的分区切换与数据保护OTA场景下串门还有一层特殊含义新固件可能和旧固件读写不同的分区。如果旧固件用的是factory分区新固件OTA到了ota_0分区两者虽然代码逻辑一样但跑起来后对NVS和文件系统分区的访问应该是一致的。OTA本身依赖otadata分区记录当前应该从哪个分区启动。升级流程大致是下载新固件写入ota_1分区假设当前从ota_0启动。写入完成后设置otadata为下次从ota_1启动。重启bootloader读取otadata从ota_1启动。新固件自检通过后把otadata标记为确认可用如果不通过回滚到ota_0。这里面最容易出问题的是分区大小和固件大小不匹配。我遇到过固件在开发期不断膨胀某次OTA后写入失败原因是目标分区大小不够。排查时看见esp_ota_ops.c报ESP_ERR_FLASH_SIZE_NOT_MATCH这才意识到是分区规划时的余量给少了。从此之后我在规划OTA分区时有一个习惯把分区大小设为当前固件体积的1.5倍或至少多留300KB。另外如果多个小应用都在做OTA一定要明确只有一个OTA主流程不能让两个应用同时操作otadata和ota_0/ota_1分区。我见过一个设备主控逻辑和蓝牙模块都尝试触发OTA结果两个写并发把otadata写坏系统反复重启也起不来。后来的处理是在OTA入口加互斥锁并且由统一的任务管理。5. 常见问题与排查技巧实录5.1 分区表没有生效这个问题我遇到太多次了典型现象是代码里明明能找到的分区运行时报错找不到或者明明CSV里定义了很大空间实际写文件写到一半就满了。排查思路按顺序来确认烧录时确实烧了新的分区表。用esptool.py read_flash读回0x9000处的内容和本地生成的partition table bin对比。很多分区没生效其实是烧录时分区表没更新固件倒是新的分区表还是旧的。确认用的是自定义CSV。ESP-IDF默认会用内置的分区方案Arduino环境更明显需要手动选择分区方案。在PlatformIO里我会在platformio.ini里写死board_build.partitions partitions.csv避免IDE设置被无意改动。确认CSV语法和内容没有逻辑冲突。比如NVS分区和otadata分区出现多个、app分区没有按64KB对齐、分区之间重叠特别是手动指定offset时这些CSV工具会报错但有些看起来合法的重叠比如size写过了边界工具未必能发现。我自己还踩过一次特别隐蔽的坑用文本编辑器在CSV里加了带BOM的UTF-8头工具链解析第一个字段时带了隐藏字符导致找不到分区。排查了很久最后用xxd看文件头才发现。5.2 数据串门的典型症状遇到下面这些情况优先怀疑Flash隔离方案有问题症状可能原因排查方向升级固件后WiFi配置丢失NVS被擦除或NVS分区被覆盖检查是否有代码调nvs_flash_erase检查OTA写越界写日志后Web页面文件损坏日志分区和Web分区在同一文件系统拆分文件系统分区或检查文件系统分区Size溢出设备运行几天后崩溃重启日志区写满后覆盖邻接分区增加日志轮转或单独给日志分配分区OTA升级后启动异常ota分区大小不足或otadata损坏检查分区表里ota_0/ota_1大小调整otadataNVS写入返回ESP_ERR_NVS_NOT_ENOUGH_SPACENVS分区过小或namespace过多扩大NVS分区或减少存储键其中一个我印象最深的问题是设备里一个任务是采集温湿度并写日志另一个任务是Web服务器。两者共用SPIFFS分区一开始都正常但采集任务每5分钟写一条日志几天后Web页面所有图片全打不开了。表面看是图片损坏实际是日志把分区写满文件系统碎片化严重导致原先可以读取的文件被挤到不可用区域。后来把日志独立到专门分区Web页面设置format_if_mount_failedfalse且禁止日志任务跨分区访问问题彻底消失。5.3 避坑清单结合这些年的项目经验整理一份我每次做ESP32存储方案都会过一遍的清单先画分区图再写代码。任何存数据的功能动手前先明确写在哪个分区、用什么API。没有明确存储归属的功能默认不实现。减小NVS写入频率。NVS按扇区擦写频繁写入会加速Flash磨损。日志、采集数据不要用NVS用文件系统。OTA分区要比实际固件大出足够余量。建议至少1.3倍至1.5倍。每次固件体积大幅增加后回头检查分区大小是否仍够。文件系统挂载失败策略要分场景。可再生的缓存数据可以格式化珍贵日志和用户配置绝对不能自动格式化。用分区标签partition_label而不是硬编码地址。代码里用硬编码地址一旦分区表调整就全盘崩盘用API查表找分区是正道。日志和业务数据尽量分应用独立目录即使在同一文件系统分区也通过子目录约束方便误删时止损。定期做掉电测试。数据隔离方案是否可靠不能只在常温常态下验要做随机断电写入测试。ESP32在写入中途断电最容易暴露Flash隔离设计的漏洞。5.4 应急恢复数据已经被串门了怎么办最后这条是给已经出问题的朋友看的。当你发现设备数据已经被写坏先别急着格式化重来。如果只是某个分区的数据损坏可以先尝试只擦除那个分区esptool.py --port /dev/ttyUSB0 erase_region 0x328000 0xC8000这样可以保住其他分区的数据。如果整个Flash乱成一团且固件还能正常跑可以先导出NVS里还有的配置nvs_handle_t handle; nvs_open(config_ns, NVS_READONLY, handle); char ssid[32]; size_t len sizeof(ssid); if (nvs_get_str(handle, wifi_ssid, ssid, len) ESP_OK) { // 写回电脑或备份 }数据备份这个习惯真的很重要。我后来在所有项目的NVS写入流程里都加了一个配置版本号键每次写入配置时版本号加1。一旦出现异常至少能知道配置是什么时候被改的排查范围一下子缩小很多。关于现网设备的远程数据恢复还有一个技巧利用OTA流程里的esp_ota_get_running_partition区分当前固件再结合分区表做定向恢复。但这个方法需要提前在固件里预留恢复逻辑属于平时不用、关键时救命的设计值得在架构规划时就埋进去。我个人在实际操作中的体会是Flash隔离这件事越早做成本越低。等代码写了几万行再回来调整分区表等于给一栋已经住满人的楼重新改户型牵一发动全身。新项目开始的那天花半小时画一张分区图后面能省下几天甚至几周的排查时间。另外多说一句分区方案不是一劳永逸的固件体积、日志策略、功能数量都会变每次版本迭代都回头瞄一眼分区表这个习惯帮我避开了不少线上事故。