在ESP32上跑多个功能模块或独立小应用是很多产品的常态一个负责联网配置一个存传感器校准一个写运行日志一个管OTA升级。大家共用同一块几兆的Flash最怕的往往不是空间不够而是数据“串门”——你写你的、我写我的结果A模块刚写完的配置转头被B模块冲掉或者OTA烧了个新固件直接把日志分区顶穿。先给结论想不串门核心就三个字——划边界。把分区表做对把命名空间分开把文件系统独立同时所有写Flash的操作都通过分区API来做而不是拿着地址直接写。这篇文章就围绕ESP32的Flash数据隔离展开把方案和坑都说透适合正在用ESP-IDF或Arduino做多应用、多业务模块开发的人也适合想把单分区项目改造成多应用隔离的工程师。1. 先搞清楚“串门”到底是怎么发生的1.1 同一块Flash上多个小应用的常见共存方式很多人以为“多个小应用”是像手机App那样一个个安装、卸载、更新。但在ESP32上实际情况通常是下面这三种一个固件里的多个业务模块同一个app二进制里WiFi配网模块、传感器校准模块、日志缓存模块、用户偏好模块各自独立由不同团队或不同线程维护。多固件多分区共存一个Flash里烧录了多个独立固件分别放在不同的app分区通过OTA切换或者启动参数选择运行哪个。数据分区上的业务分离设备本身只有一个主固件但用户数据、日志、素材包、设备证书这些数据要分开管理不能混在一个文件系统里。不管是哪种都有一个共同点Flash被所有模块“看得见、摸得着”。ESP32的Flash是线性地址映射并没有为不同软件模块提供“分区级硬件隔离”。任何一段运行中的代码只要知道一个物理地址就可以擦写那一段区域。这就注定“数据隔离”必须从工程架构上主动设计而不是靠芯片默认保护。1.2 串门的三种典型路径根据我这些年看到的踩坑案例Flash数据串门基本只有三条路径路径一分区表重叠。自定义分区表时Offset或Size抄错两个分区标到了同一块区域。这种问题最隐蔽平时只写几十字节数据时根本看不出来等某个模块把分区写满另一个模块的数据就开始被随机覆盖。路径二NVS键冲突。NVS是ESP-IDF默认的键值存储很多人图省事所有模块都用同一个namespace、同一个key存数据。比如A模块用nvs_set_i32(config)B模块也用nvs_set_i32(config)后执行者直接覆盖先执行者的值。这种“逻辑串门”在代码层面很难一眼发现。路径三裸地址写Flash。没有走任何分区API直接调spi_flash_write或esp_flash_write。有人觉得“我只要算好地址不越界就行”但地址计算很容易出错尤其是经过OTA升级、分区表调整之后原先算好的偏移可能完全失效一口气写到bootloader区域整块板子直接变砖。理解了这三条路径就能明白数据隔离到底要解决什么问题一是地址边界要清晰二是键名逻辑要分开三是操作动作要受控。下面我按层级从分区表讲到NVS再讲到文件系统最后讲防越界机制。2. 用分区表给每个应用划出独立房间2.1 先认识ESP32的Flash布局ESP32的Flash通常是4MB、8MB或16MB出厂时物理上从地址0开始排列。默认布局大致是0x0000Flash加密相关元数据、预留区域0x1000Bootloader0x8000分区表Partition Table0x9000NVS分区存放设备参数、WiFi配置0xE000PHY初始化数据0x10000App固件分区分区表是一个固定格式的二进制文件里面记录每个分区的类型、子类型、起始地址、大小。ESP-IDF启动时会解析这张表决定从哪里加载App、哪个分区挂到哪个文件系统。SoC本身并不强制校验分区之间的边界它只是“照着表执行”。所以分区表一旦写错后果就是整个存储地图乱了套。2.2 如何定制自己的分区表在ESP-IDF工程里分区表通常是一个partitions.csv文件。默认在menuconfig里选择Partition Table Custom partition table CSV然后指定CSV路径即可。CSV的格式很简单# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, phy_init, data, phy, 0xD000, 0x1000, factory, app, factory, 0x10000, 0x1E0000,每一行代表一个分区。Offset是起始地址Size是大小这两个值决定了分区占用的物理范围。如果两个分区的Offset和Size存在重叠ESP-IDF在生成分区表时其实会报错但很多人图省事会用“自动分配”——也就是Offset留空让工具自动计算。自动分配的好处是省事坏处是不同版本工具算法有差异尤其当你手动调了某个分区的Size后续分区可能整体偏移难以直观估算最终布局。我个人建议所有Offset都手写并且用十六进制直观对齐。下面是个例子# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, phy_init, data, phy, 0xD000, 0x1000, factory, app, factory, 0x10000, 0x1E0000, app_a_nvs, data, nvs, 0x1F0000, 0x4000, app_b_nvs, data, nvs, 0x1F4000, 0x4000, app_a_fs, data, spiffs, 0x1F8000, 0x20000, app_b_fs, data, spiffs, 0x218000, 0x20000,注意所有Offset和Size都建议按64KB对齐。原因很简单ESP32的Flash MMU映射页通常是64KBflash加密也要求某些分区对齐到64KB。虽然理论上4KB粒度也能工作但实测中64KB对齐能减少很多映射和加密相关的边界问题。2.3 给每个应用分配独立数据分区的思路上面这个CSV里系统区域仍然是最前面的NVS和PHY接着是一个Factory App分区。从0x1F0000开始我把剩余的Flash切成四个独立数据分区app_a_nvs、app_b_nvs分别给两个应用存小配置app_a_fs、app_b_fs分别给两个应用做文件存储。这样设计的好处非常明显删除不影响A应用即使执行整分区擦除物理上也只影响app_a_nvs和app_a_fsB应用的数据纹丝不动。容量可预期每个应用能用的空间是固定的不会出现“A应用把文件写满导致B应用文件系统没空间”的问题。升级可替代如果未来要OTA单个应用的固件只要把某个app分区替换成OTA分区即可数据分区保持独立。这个“一个应用对应一个NVS加一个FS”的组合是我做多业务模块时最常用的一套隔离单元。单个应用内部不再需要担心和其他应用抢空间。3. NVS命名空间是隔离的第一道墙3.1 NVS的命名空间到底是什么NVSNon-Volatile Storage是ESP-IDF提供的一套键值对存储专门用来保存小参数。它内部的管理方式是先按“namespace”分一层再在namespace里存“key-value”。可以这样理解namespace相当于衣柜里的抽屉key是抽屉里的物品。两个抽屉都可以放一件叫“毛衣”的衣服物理上互不影响。所以只要不同模块使用不同的namespace即使key同名也不会互相覆盖。这一点是整个NVS隔离设计的基石。默认情况下所有应用都用同一个NVS分区。比如在IDF里直接调用nvs_handle_t handle; ESP_ERROR_CHECK(nvs_open(wifi_store, NVS_READWRITE, handle)); ESP_ERROR_CHECK(nvs_set_i32(handle, enabled, 1)); ESP_ERROR_CHECK(nvs_commit(handle)); nvs_close(handle);另一个模块只要把wifi_store改成sensor_store就可以放心使用enabled这个key。两个key都叫enabled但位于不同namespace读写的值完全不同。3.2 命名空间不能替代物理分区隔离这里必须泼一盆冷水namespace只是逻辑隔离不是物理隔离。所有namespace仍然共享同一个NVS物理分区。如果某个模块调用了nvs_erase_all(nvs_get_default_partition())这个分区里所有namespace都会被清空无论你用的是wifi_store还是sensor_store。所以如果项目里存在“某些模块有恢复出厂设置权限但其他模块的配置不能被清掉”的场景就必须把NVS拆到不同的物理分区。ESP-IDF提供了nvs_open_from_partition接口可以指定分区名打开NVS句柄nvs_handle_t handle; esp_err_t err nvs_open_from_partition(app_a_nvs, store, NVS_READWRITE, handle); if (err ESP_OK) { nvs_set_i32(handle, calibration, 1234); nvs_commit(handle); nvs_close(handle); }关键点是app_a_nvs这个分区必须真实存在于分区表中也就是上一节CSV里定义的data, nvs, labelapp_a_nvs。这样A应用即使对整个app_a_nvs分区做擦除B应用所在的app_b_nvs仍然安全。简单说namespace解决“键冲突”物理分区解决“擦除级事故”。3.3 我踩过的NVS坑第一个坑是名字长度。IDF对namespace和key的长度限制比较严格一般不能超过15个字符左右。我一开始喜欢用module_1_wifi_config这种长名编译能过运行后nvs_open返回ESP_ERR_NVS_KEY_TOO_LONG排查了半天。后来统一改成短名字例如wifi_cfg。第二个坑是写入后必须nvs_commit。nvs_set_i32之类只是把数据写入内存缓存如果紧接着掉电重启数据可能丢失。必须调用nvs_commit(handle)真正提交到Flash。第三个坑是别把NVS当文件系统用。NVS一条记录最大也就2KB左右如果某个模块要存几十KB的JSON配置放NVS不但容易写满页还会频繁触发垃圾回收和磨损均衡。遇到这种情况应该把大数据量内容放进文件系统分区NVS只存文件路径和校验值。4. 文件系统分区SPIFFS/LittleFS怎么真正做到互不干扰4.1 为什么不能把所有文件都丢进同一个文件系统很多项目一开始图省事把日志、配置、用户素材全部放在同一个SPIFFS或LittleFS分区里。短时间内没问题但运行一段时间后就会碰到日志循环写把整个文件系统填满配置保存失败或者两个模块都创建一个叫data.txt的文件后写入的覆盖了先写入的。文件系统给你提供的是“文件名”抽象但它并没有为不同业务模块提供“目录权限隔离”。即使你建立子目录那也只是约定不是强制。只要其中一个模块的程序出错它可以遍历根目录删掉任何文件。想从根本上隔离就必须给每个应用分配独立的文件系统分区。4.2 用分区label挂载多个文件系统ESP-IDF的esp_vfs_spiffs_register接口支持指定partition_label。只要分区表里有对应label的分区应用就可以把不同分区挂载到不同路径。看这段代码esp_vfs_spiffs_conf_t conf_a { .base_path /a, .partition_label app_a_fs, .max_files 5, .format_if_mount_failed true, }; ESP_ERROR_CHECK(esp_vfs_spiffs_register(conf_a)); esp_vfs_spiffs_conf_t conf_b { .base_path /b, .partition_label app_b_fs, .max_files 5, .format_if_mount_failed true, }; ESP_ERROR_CHECK(esp_vfs_spiffs_register(conf_b));注册完成后A模块只能看到/a下的文件B模块只能看到/b下的文件。即使两边都有data.txt物理上也分属不同分区互不影响。LittleFS的用法几乎一样只需要把esp_vfs_spiffs_register换成esp_littlefs_register配置结构体也差不多。如果是从零开始的新项目我更推荐LittleFS它对掉电恢复和目录操作的支持比SPIFFS好不少。4.3 文件系统分区的大小和磨损考虑每次擦写都会消耗Flash寿命典型NOR Flash的擦写寿命约10万次。如果多个应用共用一个文件系统一个模块疯狂写日志会让另一个模块的存储区“被动陪跑”坏块率上升。独立分区之后每个模块各自承担自己的磨损互不拖累。但独立分区也要注意两点一是分区大小不要卡太紧文件系统本身需要预留一定空间做GC和坏块替换建议留出20%左右的余量二是日志类高频写入不要直接落在SPIFFS或LittleFS的小分区里更稳的做法是先在RAM里缓冲批量写入或者把日志放到单独的大容量分区循环覆盖。5. 越界防护写给Flash的正确姿势5.1 为什么不要用裸地址直接写Flash在Arduino生态或其他单片机驱动外部Flash的经验里很多人习惯用spi_flash_write(addr, data, len)这种“地址自由发挥”的写法。在ESP32上这非常危险。你手上这块Flash不但存着应用数据还存有bootloader和分区表。写错一个地址轻则数据污染重则整板变砖。ESP-IDF提供了一套分区API核心思想是你不直接指定物理地址而是先通过分区表拿到一个esp_partition_t结构体再用它对分区内部偏移进行读写。API内部会检查你传入的偏移和长度是否超出分区范围一旦越界就返回错误这就是一道硬性保险。下面是对比// 错误做法直接算物理地址 uint32_t addr 0x1F8000 offset; spi_flash_erase_sector(addr / 4096); spi_flash_write(addr, data, len); // 正确做法通过分区API const esp_partition_t* part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, app_a_fs); if (part NULL) { return ESP_ERR_NOT_FOUND; } esp_partition_erase_range(part, 0, part-size); esp_partition_write(part, 0, data, len);第二种写法一旦传入的len超过part-sizeesp_partition_write会直接拒绝执行。你不需要自己在每个调用点手工判断这个边界检查就是用来防止“串门”的最后一道闸门。5.2 OTA升级时的越界风险OTA是另一个容易出现越界的地方。很多人图省事拿到固件数据后直接往App分区的物理地址写。但OTA固件可能比你想象的大如果写入长度超出目标分区范围旧数据会被部分覆盖新固件也校验失败。正确做法是使用esp_ota_begin、esp_ota_write和esp_ota_end这一组接口。其中esp_ota_begin会检查你传入的image大小和分区容量如果超了直接返回错误。整个OTA过程不需要你手工计算物理地址所有写入都由OTA实现接管。OTA完成后还必须调用esp_ota_end做完整性校验校验通过才标记为可启动分区。5.3 关于eFuse和Flash加密的提醒很多朋友会问开了Flash加密数据是不是就不会串门了答案是不能。Flash加密解决的是“外部读芯片”攻击不是“内部应用代码互相越权访问”。只要代码运行在同一个CPU上它仍然可以通过空中解析分区API或直接调底层的Flash驱动去写它不该写的区域。所以不要指望芯片提供应用级内存隔离。ESP32不像PC有虚拟内存的进程隔离它默认情况下所有代码都运行在同一特权级。真正的隔离核心是“代码自律架构约束”。分区API的边界检查是约束命名空间和分区表是划分剩下的就要靠开发者在代码评审时确保每个模块只操作自己的label。6. 常见的串门现场与排查技巧实录6.1 现场一A模块跑完后B模块配置被清零这是个真实案例。有一个设备带WiFi配网和传感器校准两个模块都在NVS里存配置。调试时发现每次重新配网后传感器校准值就会变回默认值。检查代码后确认两个模块都用了同一个namespace甚至key名字也一样。WiFi模块写入calibration时实际是在覆盖传感器模块的数据。解决方案有两个如果不想改物理分区最简单就是把两个模块的namespace改成完全不同的名字例如wifi和sensor_cal如果要更强的隔离就按前面说的给每个模块单独分配一个NVS物理分区然后用nvs_open_from_partition隔离。排查步骤可以这样走打开代码搜索所有nvs_open和Preferences.begin调用看namespace有没有重复。如果所有模块都用默认namespace比如Arduino库里的Preferences.begin(settings)那就极可能发生同名覆盖。在关键数据写入前打印key名和值观察是否被其他模块改写。6.2 现场二OTA升级后日志目录乱码还有一台设备主固件是OTA升级日志写在App分区后面的独立FAT分区。某次OTA升级后日志文件全部变成乱码甚至文件系统挂载失败。查分区表发现App分区Size设置得刚好够旧固件但新固件多了几十KBOTA写入时超出了App分区把紧邻的日志分区头部覆盖了。这种问题的根源就是分区表Size太“极限”。经验是给App分区预留至少20%的余量或者在App分区和数据分区之间故意空出一段gap。比如我在模板里经常写成factory, app, factory, 0x10000, 0x1D8000让App分区结束地址比下一个数据分区起始地址小一块这样OTA即使稍微写多几KB也不会直接冲到下一个分区。排查方法重新读回分区表确认实际烧录的分区与CSV一致。查看OTA日志中esp_ota_begin的image size和分区表实际Size对比。如果数据分区头部出现乱多半就是相邻分区越界了。6.3 现场三不同应用共用同一个文件系统导致文件损坏一个设备有A、B两个业务模块它们都直接挂载同一个SPIFFS分区。A模块写/log.txtB模块写/data.txt表面上文件不重名但B模块在启动时执行了一个“清理过期文件”的流程结果误删了整个根目录下的所有文件A模块的日志也跟着遭殃。这种问题不是文件重名而是“管理权没有隔离”。解决方式仍然是独立分区A和B各自挂载自己的SPIFFS大分区谁也不能碰对方的根目录。如果实在不想改分区表就必须在代码层面做文件命名前缀约束比如A模块只允许操作/a_开头的文件并在删除操作里加白名单校验。6.4 快速自检隔离性的测试思路当你把分区表和命名空间都改完后怎么确认隔离真的生效我一般会在开发板上跑一组简单的自检每个模块启动时写一个固定magic值到自己的NVS和文件系统。切换运行另一个模块然后读取前一个模块的magic预期应该保持原值。让A模块尝试读取B模块的namespace。注意这不一定返回“拒绝访问”它可能返回“找不到key”。这个结果反而是对的说明数据边界已经分开。让A模块尝试直接写B模块的FS路径因为挂载点不同应该得到ENOENT或类似错误。用esp_partition_find_first遍历所有data分区确认分区表的每个分区范围不重叠。这套流程下来基本能覆盖绝大多数数据串门问题。6.5 常见误区速查表误区后果正确做法所有模块共用同一个NVS namespace同名key互相覆盖每个模块独立namespace或者独立NVS分区多个模块共用同一个文件系统分区文件互相删除或覆盖独立分区并挂载不同路径手工计算Flash物理地址写入覆盖bootloader或分区表使用esp_partition_*APIOTA App分区Size卡得刚刚好升级写越界破坏相邻分区预留20%余量留gap一个模块执行整分区擦除其他模块数据被清空将需要保留的数据拆到独立分区7. 给你一套可以直接用的分区表模板最后一个部分我贴一套我实际验证过的4MB Flash分区模板。它支持一个主固件、两个独立数据应用系统NVS和PHY保持默认主App分区留了余量两个应用分别有自己的NVS和LittleFS数据分区。# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, otadata, data, ota, 0xD000, 0x2000, phy_init, data, phy, 0xF000, 0x1000, factory, app, factory, 0x10000, 0x1D8000, app_a_nvs, data, nvs, 0x1E8000, 0x4000, app_b_nvs, data, nvs, 0x1EC000, 0x4000, app_a_fs, data, spiffs, 0x1F0000, 0x18000, app_b_fs, data, spiffs, 0x208000, 0x18000,这个模板里我把app_a_nvs和app_a_fs放在一起app_b_nvs和app_b_fs放在一起逻辑分区从高到低排列避免和App分区挤在一起。factory分区结束地址是0x1E8000而app_a_nvs起始也是0x1E8000中间没有gap所以如果你的固件会超过当前Size必须提前调大factorySize或者把后面所有分区整体后移。我更建议在实际量产时把App Size再调小一些留出一段0x4000的空闲区做缓冲。另外如果你需要支持两个独立固件的OTA分别升级可以把factory分区替换成两个OTA分区和一个otadata分区但数据隔离思路不变。无非就是app类型有多个实例data类型保持独立。最后说一点个人体会做多应用共享Flash时不要迷信“芯片会保护数据”要相信“分区表是宪法API是执法者”。把分区表设计得清清楚楚每个模块只允许用自己label下的资源所有写入都通过esp_partition_*、nvs_open_from_partition、esp_vfs_*这些接口数据串门的问题就能在架构层面被消除掉。我之前踩过不少坑后来统一成这套模板和流程再也没因为Flash覆盖问题返过工。 
长河君 · 2026/10/2 1:26:47 · 阅读 1.2k ESP32 Flash数据隔离实战：分区表、NVS与文件系统防串门
在ESP32上跑多个功能模块或独立小应用是很多产品的常态一个负责联网配置一个存传感器校准一个写运行日志一个管OTA升级。大家共用同一块几兆的Flash最怕的往往不是空间不够而是数据“串门”——你写你的、我写我的结果A模块刚写完的配置转头被B模块冲掉或者OTA烧了个新固件直接把日志分区顶穿。先给结论想不串门核心就三个字——划边界。把分区表做对把命名空间分开把文件系统独立同时所有写Flash的操作都通过分区API来做而不是拿着地址直接写。这篇文章就围绕ESP32的Flash数据隔离展开把方案和坑都说透适合正在用ESP-IDF或Arduino做多应用、多业务模块开发的人也适合想把单分区项目改造成多应用隔离的工程师。1. 先搞清楚“串门”到底是怎么发生的1.1 同一块Flash上多个小应用的常见共存方式很多人以为“多个小应用”是像手机App那样一个个安装、卸载、更新。但在ESP32上实际情况通常是下面这三种一个固件里的多个业务模块同一个app二进制里WiFi配网模块、传感器校准模块、日志缓存模块、用户偏好模块各自独立由不同团队或不同线程维护。多固件多分区共存一个Flash里烧录了多个独立固件分别放在不同的app分区通过OTA切换或者启动参数选择运行哪个。数据分区上的业务分离设备本身只有一个主固件但用户数据、日志、素材包、设备证书这些数据要分开管理不能混在一个文件系统里。不管是哪种都有一个共同点Flash被所有模块“看得见、摸得着”。ESP32的Flash是线性地址映射并没有为不同软件模块提供“分区级硬件隔离”。任何一段运行中的代码只要知道一个物理地址就可以擦写那一段区域。这就注定“数据隔离”必须从工程架构上主动设计而不是靠芯片默认保护。1.2 串门的三种典型路径根据我这些年看到的踩坑案例Flash数据串门基本只有三条路径路径一分区表重叠。自定义分区表时Offset或Size抄错两个分区标到了同一块区域。这种问题最隐蔽平时只写几十字节数据时根本看不出来等某个模块把分区写满另一个模块的数据就开始被随机覆盖。路径二NVS键冲突。NVS是ESP-IDF默认的键值存储很多人图省事所有模块都用同一个namespace、同一个key存数据。比如A模块用nvs_set_i32(config)B模块也用nvs_set_i32(config)后执行者直接覆盖先执行者的值。这种“逻辑串门”在代码层面很难一眼发现。路径三裸地址写Flash。没有走任何分区API直接调spi_flash_write或esp_flash_write。有人觉得“我只要算好地址不越界就行”但地址计算很容易出错尤其是经过OTA升级、分区表调整之后原先算好的偏移可能完全失效一口气写到bootloader区域整块板子直接变砖。理解了这三条路径就能明白数据隔离到底要解决什么问题一是地址边界要清晰二是键名逻辑要分开三是操作动作要受控。下面我按层级从分区表讲到NVS再讲到文件系统最后讲防越界机制。2. 用分区表给每个应用划出独立房间2.1 先认识ESP32的Flash布局ESP32的Flash通常是4MB、8MB或16MB出厂时物理上从地址0开始排列。默认布局大致是0x0000Flash加密相关元数据、预留区域0x1000Bootloader0x8000分区表Partition Table0x9000NVS分区存放设备参数、WiFi配置0xE000PHY初始化数据0x10000App固件分区分区表是一个固定格式的二进制文件里面记录每个分区的类型、子类型、起始地址、大小。ESP-IDF启动时会解析这张表决定从哪里加载App、哪个分区挂到哪个文件系统。SoC本身并不强制校验分区之间的边界它只是“照着表执行”。所以分区表一旦写错后果就是整个存储地图乱了套。2.2 如何定制自己的分区表在ESP-IDF工程里分区表通常是一个partitions.csv文件。默认在menuconfig里选择Partition Table Custom partition table CSV然后指定CSV路径即可。CSV的格式很简单# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, phy_init, data, phy, 0xD000, 0x1000, factory, app, factory, 0x10000, 0x1E0000,每一行代表一个分区。Offset是起始地址Size是大小这两个值决定了分区占用的物理范围。如果两个分区的Offset和Size存在重叠ESP-IDF在生成分区表时其实会报错但很多人图省事会用“自动分配”——也就是Offset留空让工具自动计算。自动分配的好处是省事坏处是不同版本工具算法有差异尤其当你手动调了某个分区的Size后续分区可能整体偏移难以直观估算最终布局。我个人建议所有Offset都手写并且用十六进制直观对齐。下面是个例子# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, phy_init, data, phy, 0xD000, 0x1000, factory, app, factory, 0x10000, 0x1E0000, app_a_nvs, data, nvs, 0x1F0000, 0x4000, app_b_nvs, data, nvs, 0x1F4000, 0x4000, app_a_fs, data, spiffs, 0x1F8000, 0x20000, app_b_fs, data, spiffs, 0x218000, 0x20000,注意所有Offset和Size都建议按64KB对齐。原因很简单ESP32的Flash MMU映射页通常是64KBflash加密也要求某些分区对齐到64KB。虽然理论上4KB粒度也能工作但实测中64KB对齐能减少很多映射和加密相关的边界问题。2.3 给每个应用分配独立数据分区的思路上面这个CSV里系统区域仍然是最前面的NVS和PHY接着是一个Factory App分区。从0x1F0000开始我把剩余的Flash切成四个独立数据分区app_a_nvs、app_b_nvs分别给两个应用存小配置app_a_fs、app_b_fs分别给两个应用做文件存储。这样设计的好处非常明显删除不影响A应用即使执行整分区擦除物理上也只影响app_a_nvs和app_a_fsB应用的数据纹丝不动。容量可预期每个应用能用的空间是固定的不会出现“A应用把文件写满导致B应用文件系统没空间”的问题。升级可替代如果未来要OTA单个应用的固件只要把某个app分区替换成OTA分区即可数据分区保持独立。这个“一个应用对应一个NVS加一个FS”的组合是我做多业务模块时最常用的一套隔离单元。单个应用内部不再需要担心和其他应用抢空间。3. NVS命名空间是隔离的第一道墙3.1 NVS的命名空间到底是什么NVSNon-Volatile Storage是ESP-IDF提供的一套键值对存储专门用来保存小参数。它内部的管理方式是先按“namespace”分一层再在namespace里存“key-value”。可以这样理解namespace相当于衣柜里的抽屉key是抽屉里的物品。两个抽屉都可以放一件叫“毛衣”的衣服物理上互不影响。所以只要不同模块使用不同的namespace即使key同名也不会互相覆盖。这一点是整个NVS隔离设计的基石。默认情况下所有应用都用同一个NVS分区。比如在IDF里直接调用nvs_handle_t handle; ESP_ERROR_CHECK(nvs_open(wifi_store, NVS_READWRITE, handle)); ESP_ERROR_CHECK(nvs_set_i32(handle, enabled, 1)); ESP_ERROR_CHECK(nvs_commit(handle)); nvs_close(handle);另一个模块只要把wifi_store改成sensor_store就可以放心使用enabled这个key。两个key都叫enabled但位于不同namespace读写的值完全不同。3.2 命名空间不能替代物理分区隔离这里必须泼一盆冷水namespace只是逻辑隔离不是物理隔离。所有namespace仍然共享同一个NVS物理分区。如果某个模块调用了nvs_erase_all(nvs_get_default_partition())这个分区里所有namespace都会被清空无论你用的是wifi_store还是sensor_store。所以如果项目里存在“某些模块有恢复出厂设置权限但其他模块的配置不能被清掉”的场景就必须把NVS拆到不同的物理分区。ESP-IDF提供了nvs_open_from_partition接口可以指定分区名打开NVS句柄nvs_handle_t handle; esp_err_t err nvs_open_from_partition(app_a_nvs, store, NVS_READWRITE, handle); if (err ESP_OK) { nvs_set_i32(handle, calibration, 1234); nvs_commit(handle); nvs_close(handle); }关键点是app_a_nvs这个分区必须真实存在于分区表中也就是上一节CSV里定义的data, nvs, labelapp_a_nvs。这样A应用即使对整个app_a_nvs分区做擦除B应用所在的app_b_nvs仍然安全。简单说namespace解决“键冲突”物理分区解决“擦除级事故”。3.3 我踩过的NVS坑第一个坑是名字长度。IDF对namespace和key的长度限制比较严格一般不能超过15个字符左右。我一开始喜欢用module_1_wifi_config这种长名编译能过运行后nvs_open返回ESP_ERR_NVS_KEY_TOO_LONG排查了半天。后来统一改成短名字例如wifi_cfg。第二个坑是写入后必须nvs_commit。nvs_set_i32之类只是把数据写入内存缓存如果紧接着掉电重启数据可能丢失。必须调用nvs_commit(handle)真正提交到Flash。第三个坑是别把NVS当文件系统用。NVS一条记录最大也就2KB左右如果某个模块要存几十KB的JSON配置放NVS不但容易写满页还会频繁触发垃圾回收和磨损均衡。遇到这种情况应该把大数据量内容放进文件系统分区NVS只存文件路径和校验值。4. 文件系统分区SPIFFS/LittleFS怎么真正做到互不干扰4.1 为什么不能把所有文件都丢进同一个文件系统很多项目一开始图省事把日志、配置、用户素材全部放在同一个SPIFFS或LittleFS分区里。短时间内没问题但运行一段时间后就会碰到日志循环写把整个文件系统填满配置保存失败或者两个模块都创建一个叫data.txt的文件后写入的覆盖了先写入的。文件系统给你提供的是“文件名”抽象但它并没有为不同业务模块提供“目录权限隔离”。即使你建立子目录那也只是约定不是强制。只要其中一个模块的程序出错它可以遍历根目录删掉任何文件。想从根本上隔离就必须给每个应用分配独立的文件系统分区。4.2 用分区label挂载多个文件系统ESP-IDF的esp_vfs_spiffs_register接口支持指定partition_label。只要分区表里有对应label的分区应用就可以把不同分区挂载到不同路径。看这段代码esp_vfs_spiffs_conf_t conf_a { .base_path /a, .partition_label app_a_fs, .max_files 5, .format_if_mount_failed true, }; ESP_ERROR_CHECK(esp_vfs_spiffs_register(conf_a)); esp_vfs_spiffs_conf_t conf_b { .base_path /b, .partition_label app_b_fs, .max_files 5, .format_if_mount_failed true, }; ESP_ERROR_CHECK(esp_vfs_spiffs_register(conf_b));注册完成后A模块只能看到/a下的文件B模块只能看到/b下的文件。即使两边都有data.txt物理上也分属不同分区互不影响。LittleFS的用法几乎一样只需要把esp_vfs_spiffs_register换成esp_littlefs_register配置结构体也差不多。如果是从零开始的新项目我更推荐LittleFS它对掉电恢复和目录操作的支持比SPIFFS好不少。4.3 文件系统分区的大小和磨损考虑每次擦写都会消耗Flash寿命典型NOR Flash的擦写寿命约10万次。如果多个应用共用一个文件系统一个模块疯狂写日志会让另一个模块的存储区“被动陪跑”坏块率上升。独立分区之后每个模块各自承担自己的磨损互不拖累。但独立分区也要注意两点一是分区大小不要卡太紧文件系统本身需要预留一定空间做GC和坏块替换建议留出20%左右的余量二是日志类高频写入不要直接落在SPIFFS或LittleFS的小分区里更稳的做法是先在RAM里缓冲批量写入或者把日志放到单独的大容量分区循环覆盖。5. 越界防护写给Flash的正确姿势5.1 为什么不要用裸地址直接写Flash在Arduino生态或其他单片机驱动外部Flash的经验里很多人习惯用spi_flash_write(addr, data, len)这种“地址自由发挥”的写法。在ESP32上这非常危险。你手上这块Flash不但存着应用数据还存有bootloader和分区表。写错一个地址轻则数据污染重则整板变砖。ESP-IDF提供了一套分区API核心思想是你不直接指定物理地址而是先通过分区表拿到一个esp_partition_t结构体再用它对分区内部偏移进行读写。API内部会检查你传入的偏移和长度是否超出分区范围一旦越界就返回错误这就是一道硬性保险。下面是对比// 错误做法直接算物理地址 uint32_t addr 0x1F8000 offset; spi_flash_erase_sector(addr / 4096); spi_flash_write(addr, data, len); // 正确做法通过分区API const esp_partition_t* part esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_SPIFFS, app_a_fs); if (part NULL) { return ESP_ERR_NOT_FOUND; } esp_partition_erase_range(part, 0, part-size); esp_partition_write(part, 0, data, len);第二种写法一旦传入的len超过part-sizeesp_partition_write会直接拒绝执行。你不需要自己在每个调用点手工判断这个边界检查就是用来防止“串门”的最后一道闸门。5.2 OTA升级时的越界风险OTA是另一个容易出现越界的地方。很多人图省事拿到固件数据后直接往App分区的物理地址写。但OTA固件可能比你想象的大如果写入长度超出目标分区范围旧数据会被部分覆盖新固件也校验失败。正确做法是使用esp_ota_begin、esp_ota_write和esp_ota_end这一组接口。其中esp_ota_begin会检查你传入的image大小和分区容量如果超了直接返回错误。整个OTA过程不需要你手工计算物理地址所有写入都由OTA实现接管。OTA完成后还必须调用esp_ota_end做完整性校验校验通过才标记为可启动分区。5.3 关于eFuse和Flash加密的提醒很多朋友会问开了Flash加密数据是不是就不会串门了答案是不能。Flash加密解决的是“外部读芯片”攻击不是“内部应用代码互相越权访问”。只要代码运行在同一个CPU上它仍然可以通过空中解析分区API或直接调底层的Flash驱动去写它不该写的区域。所以不要指望芯片提供应用级内存隔离。ESP32不像PC有虚拟内存的进程隔离它默认情况下所有代码都运行在同一特权级。真正的隔离核心是“代码自律架构约束”。分区API的边界检查是约束命名空间和分区表是划分剩下的就要靠开发者在代码评审时确保每个模块只操作自己的label。6. 常见的串门现场与排查技巧实录6.1 现场一A模块跑完后B模块配置被清零这是个真实案例。有一个设备带WiFi配网和传感器校准两个模块都在NVS里存配置。调试时发现每次重新配网后传感器校准值就会变回默认值。检查代码后确认两个模块都用了同一个namespace甚至key名字也一样。WiFi模块写入calibration时实际是在覆盖传感器模块的数据。解决方案有两个如果不想改物理分区最简单就是把两个模块的namespace改成完全不同的名字例如wifi和sensor_cal如果要更强的隔离就按前面说的给每个模块单独分配一个NVS物理分区然后用nvs_open_from_partition隔离。排查步骤可以这样走打开代码搜索所有nvs_open和Preferences.begin调用看namespace有没有重复。如果所有模块都用默认namespace比如Arduino库里的Preferences.begin(settings)那就极可能发生同名覆盖。在关键数据写入前打印key名和值观察是否被其他模块改写。6.2 现场二OTA升级后日志目录乱码还有一台设备主固件是OTA升级日志写在App分区后面的独立FAT分区。某次OTA升级后日志文件全部变成乱码甚至文件系统挂载失败。查分区表发现App分区Size设置得刚好够旧固件但新固件多了几十KBOTA写入时超出了App分区把紧邻的日志分区头部覆盖了。这种问题的根源就是分区表Size太“极限”。经验是给App分区预留至少20%的余量或者在App分区和数据分区之间故意空出一段gap。比如我在模板里经常写成factory, app, factory, 0x10000, 0x1D8000让App分区结束地址比下一个数据分区起始地址小一块这样OTA即使稍微写多几KB也不会直接冲到下一个分区。排查方法重新读回分区表确认实际烧录的分区与CSV一致。查看OTA日志中esp_ota_begin的image size和分区表实际Size对比。如果数据分区头部出现乱多半就是相邻分区越界了。6.3 现场三不同应用共用同一个文件系统导致文件损坏一个设备有A、B两个业务模块它们都直接挂载同一个SPIFFS分区。A模块写/log.txtB模块写/data.txt表面上文件不重名但B模块在启动时执行了一个“清理过期文件”的流程结果误删了整个根目录下的所有文件A模块的日志也跟着遭殃。这种问题不是文件重名而是“管理权没有隔离”。解决方式仍然是独立分区A和B各自挂载自己的SPIFFS大分区谁也不能碰对方的根目录。如果实在不想改分区表就必须在代码层面做文件命名前缀约束比如A模块只允许操作/a_开头的文件并在删除操作里加白名单校验。6.4 快速自检隔离性的测试思路当你把分区表和命名空间都改完后怎么确认隔离真的生效我一般会在开发板上跑一组简单的自检每个模块启动时写一个固定magic值到自己的NVS和文件系统。切换运行另一个模块然后读取前一个模块的magic预期应该保持原值。让A模块尝试读取B模块的namespace。注意这不一定返回“拒绝访问”它可能返回“找不到key”。这个结果反而是对的说明数据边界已经分开。让A模块尝试直接写B模块的FS路径因为挂载点不同应该得到ENOENT或类似错误。用esp_partition_find_first遍历所有data分区确认分区表的每个分区范围不重叠。这套流程下来基本能覆盖绝大多数数据串门问题。6.5 常见误区速查表误区后果正确做法所有模块共用同一个NVS namespace同名key互相覆盖每个模块独立namespace或者独立NVS分区多个模块共用同一个文件系统分区文件互相删除或覆盖独立分区并挂载不同路径手工计算Flash物理地址写入覆盖bootloader或分区表使用esp_partition_*APIOTA App分区Size卡得刚刚好升级写越界破坏相邻分区预留20%余量留gap一个模块执行整分区擦除其他模块数据被清空将需要保留的数据拆到独立分区7. 给你一套可以直接用的分区表模板最后一个部分我贴一套我实际验证过的4MB Flash分区模板。它支持一个主固件、两个独立数据应用系统NVS和PHY保持默认主App分区留了余量两个应用分别有自己的NVS和LittleFS数据分区。# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, otadata, data, ota, 0xD000, 0x2000, phy_init, data, phy, 0xF000, 0x1000, factory, app, factory, 0x10000, 0x1D8000, app_a_nvs, data, nvs, 0x1E8000, 0x4000, app_b_nvs, data, nvs, 0x1EC000, 0x4000, app_a_fs, data, spiffs, 0x1F0000, 0x18000, app_b_fs, data, spiffs, 0x208000, 0x18000,这个模板里我把app_a_nvs和app_a_fs放在一起app_b_nvs和app_b_fs放在一起逻辑分区从高到低排列避免和App分区挤在一起。factory分区结束地址是0x1E8000而app_a_nvs起始也是0x1E8000中间没有gap所以如果你的固件会超过当前Size必须提前调大factorySize或者把后面所有分区整体后移。我更建议在实际量产时把App Size再调小一些留出一段0x4000的空闲区做缓冲。另外如果你需要支持两个独立固件的OTA分别升级可以把factory分区替换成两个OTA分区和一个otadata分区但数据隔离思路不变。无非就是app类型有多个实例data类型保持独立。最后说一点个人体会做多应用共享Flash时不要迷信“芯片会保护数据”要相信“分区表是宪法API是执法者”。把分区表设计得清清楚楚每个模块只允许用自己label下的资源所有写入都通过esp_partition_*、nvs_open_from_partition、esp_vfs_*这些接口数据串门的问题就能在架构层面被消除掉。我之前踩过不少坑后来统一成这套模板和流程再也没因为Flash覆盖问题返过工。