1. 一块 Flash 上塞多个应用数据串门到底是怎么发生的很多人第一次在 ESP32 上做多应用共存时都会有一个朴素的想法Flash 那么大我分几块区域各放各的数据不就行了结果跑着跑着就发现A 应用读到了 B 应用写的数据或者 OTA 升级之后配置全丢了甚至更诡异的是两个应用单独跑都没问题一起跑就随机崩溃。这类问题我前后排查过不下十次根子几乎都落在同一个地方你以为你在“分区”实际上你只是在“偏移地址上叠罗汉”。ESP32 的片内 Flash 通常有 4MB 或 8MB物理上就是一块 SPI NOR Flash。它不像 MCU 内部的 EEPROM 那样有独立的字节级擦写单元Flash 的写入规则是只能把 1 写成 0不能把 0 写回 1要恢复成 1 必须整块擦除。擦除的最小单位是扇区sector一般是 4KB。这个物理特性决定了任何两个应用如果共享同一个 4KB 扇区它们的数据就天然存在“互相擦除”的风险——哪怕你逻辑上把它们分在两个不同的偏移地址只要落在同一个扇区里一个应用触发擦除另一个应用的数据就一起没了。这就是“串门”的第一层含义物理扇区层面的越界擦除。第二层含义更隐蔽是逻辑地址映射层面的冲突。ESP32 的 NVSNon-Volatile Storage库、SPIFFS/LittleFS 文件系统、OTA 数据分区它们各自维护自己的元数据metadata。NVS 会在分区头部写页状态位文件系统会在分区开头写超级块OTA 会在 otadata 分区记录当前启动槽。如果你给两个应用分配了重叠的分区或者两个应用都往同一个 NVS 命名空间里写同名 key那读出来的数据就是“谁后写谁赢”完全不可预测。第三层是运行时缓存层面的串扰。ESP32 有 instruction cache 和 data cacheFlash 映射到地址空间后CPU 访问是走 cache 的。如果两个应用通过 mmap 方式映射了同一段 Flash 区域做只读数据而其中一个应用在运行时擦写了这段区域cache 里的旧数据不会自动失效读到的可能是“幽灵数据”。这个问题在单应用场景下很少见但多应用共用 Flash 时就会冒出来。所以回答标题里的问题保证数据不串门核心不是“分区域”而是“分扇区 分命名空间 分访问路径”三件事同时做到位。下面我按实际项目里的做法一层层拆开讲。2. 先搞清楚 ESP32 的分区表到底在管什么2.1 分区表不是“建议”是硬约束ESP32 的分区表partition table存在 Flash 偏移 0x8000 的位置默认大小 0xC003KB最多容纳 95 个分区条目。每个条目 32 字节记录了分区名、类型、子类型、偏移地址、大小、加密标志等。很多人以为分区表只是给idf.py partition-table看的实际上ESP-IDF 在启动时会校验分区表NVS、OTA、文件系统的初始化都依赖它。如果你手动在代码里往某个偏移写数据而那个偏移不在任何分区范围内启动时可能没事但一旦触发 Flash 加密或安全启动直接报错。一个典型的多应用分区表长这样# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, otadata, data, ota, 0xf000, 0x2000, phy_init, data, phy, 0x11000, 0x1000, factory, app, factory, 0x20000, 0x180000, ota_0, app, ota_0, 0x1A0000, 0x180000, ota_1, app, ota_1, 0x320000, 0x180000, storage, data, spiffs, 0x4A0000, 0x160000,这里有几个关键点容易被忽略nvs 分区默认只有 0x600024KB如果你有多个应用都要用 NVS这个大小很快就不够。NVS 的页大小是 4KB24KB 就是 6 个页每个页能存的 key-value 数量有限而且 NVS 有磨损均衡和垃圾回收机制实际可用容量大概只有标称的 60% 左右。otadata 分区固定 0x20008KB两个 4KB 扇区分别记录 ota_0 和 ota_1 的启动状态。这个分区绝对不能和别的数据混用否则 OTA 回滚会失效。app 分区必须按 64KB 对齐因为 ESP32 的 Flash 映射和 cache 是按 64KB 粒度管理的。如果你把 app 分区放在非 64KB 对齐的偏移启动直接失败。2.2 多应用共用的三种典型场景在实际项目里“多个小应用共用一块 Flash”通常对应三种架构第一种是 OTA 双槽架构。factory ota_0 ota_1 三个 app 分区同一时刻只有一个在运行但它们共享 nvs、otadata、storage 这些数据分区。这种场景下数据串门主要发生在 OTA 升级后新固件读到了旧固件写的 NVS 数据如果 key 名一样但数据结构变了就会解析出错。第二种是多 app 分区轮流启动架构。比如一个设备要支持“主控应用”和“维护应用”两个固件通过 otadata 切换启动槽。这种场景下两个应用可能各自有自己的 NVS 命名空间但如果分区表里只给了一个 nvs 分区它们就会共用同一个 NVS 实例命名空间隔离必须靠代码保证。第三种是单 app 多数据分区架构。一个固件里跑多个“逻辑小应用”比如通过 WASM 虚拟机加载不同的业务模块每个模块有自己的配置数据。这种场景下数据隔离靠的是文件系统里的不同目录或者 NVS 里的不同命名空间。不管哪种架构分区表是隔离的第一道防线但它只保证“物理不重叠”不保证“逻辑不串门”。逻辑隔离要靠 NVS 命名空间、文件系统挂载点、以及代码里的访问控制。2.3 一个真实踩坑nvs 分区被两个应用同时初始化我遇到过最典型的一次串门事故设备支持 OTAfactory 和 ota_0 两个固件都会调用nvs_flash_init()。问题出在两个固件对 NVS 的初始化参数不一样——factory 固件用的是默认分区nvsota_0 固件在某个版本里改成了自定义分区nvs_data但分区表里nvs_data的偏移和nvs有 0x1000 的重叠。结果就是ota_0 启动后往nvs_data写配置实际上写到了nvs分区的尾部把 factory 固件存的 WiFi 配网信息覆盖了。用户反馈“升级后配网信息丢失”查了两天才定位到分区重叠。这个坑的教训是分区表的偏移和大小必须用脚本自动校验不能靠人眼核对。ESP-IDF 提供了gen_esp32part.py工具可以解析分区表并检查重叠但很多人不知道它还能做这个。你可以在构建脚本里加一步python $IDF_PATH/components/partition_table/gen_esp32part.py \ --verify build/partition_table/partition-table.bin如果分区有重叠或对齐问题这一步会直接报错比等到运行时才发现要省事得多。3. NVS 命名空间最容易被忽视的隔离层3.1 NVS 的物理结构和逻辑结构NVS 是 ESP-IDF 里最常用的键值存储它的物理结构是分区被划分为多个 4KB 页每个页有一个 32 字节的页头记录页状态active/full/free/corrupt和序列号。页内是 32 字节的条目entry每个条目记录命名空间 ID、数据类型、跨度span、key 的哈希值和实际数据。NVS 的 key 最大 15 字符value 最大 4000 字节受页大小限制。逻辑上NVS 用命名空间namespace来隔离不同应用的数据。每个命名空间有一个 16 位的 ID在第一次写入时动态分配。不同命名空间下的同名 key 是完全独立的互不干扰。这就是多应用共用 NVS 时的核心隔离手段。但这里有个坑命名空间 ID 是动态分配的不是固定的。如果你在 factory 固件里先创建了命名空间app_a它拿到 ID 1然后 ota_0 固件里先创建app_b它可能也拿到 ID 1如果 NVS 被擦过。如果两个固件对命名空间的创建顺序不一致ID 映射就会错乱。虽然 NVS 内部用命名空间名字的哈希来查找理论上不会读错但如果一个固件删除了某个命名空间另一个固件还在用就会读到“命名空间不存在”的错误。3.2 多应用共用 NVS 的正确姿势我的做法是每个逻辑应用固定使用一个前缀明确的命名空间并且在代码里硬编码命名空间名字不依赖动态分配。比如// app_a 的配置读写 nvs_handle_t handle; esp_err_t err nvs_open(app_a_cfg, NVS_READWRITE, handle); if (err ! ESP_OK) { ESP_LOGE(TAG, nvs_open app_a_cfg failed: %s, esp_err_to_name(err)); return; } // 写入时用明确的 key 名 nvs_set_str(handle, wifi_ssid, ssid); nvs_commit(handle); nvs_close(handle);关键点是命名空间名字要足够独特避免哈希冲突。NVS 的命名空间名字最大 15 字符哈希是 16 位理论上不同名字可能哈希到同一个 ID但概率极低。更实际的风险是两个应用用了相似的名字比如cfg和config维护时容易搞混。我一般要求命名空间名字带应用前缀比如app_a_cfg、app_b_cfg、sys_cfg一眼就能看出归属。另外NVS 的擦除操作要格外小心。nvs_flash_erase()会擦除整个 NVS 分区所有命名空间的数据全丢。如果多个应用共用 NVS任何一个应用都不应该调用这个函数除非是在恢复出厂设置这种全局操作里。我见过一个案例某个应用在检测到配置损坏时直接调nvs_flash_erase()然后重新初始化结果把另一个应用的配网信息也擦掉了。正确的做法是只擦除自己的命名空间nvs_handle_t handle; nvs_open(app_a_cfg, NVS_READWRITE, handle); nvs_erase_all(handle); // 只擦除这个命名空间下的所有 key nvs_commit(handle); nvs_close(handle);3.3 NVS 容量规划别等到写满了才后悔NVS 分区的默认大小 0x600024KB在单应用场景下够用但多应用共用时经常不够。NVS 的可用容量不是简单的“分区大小减去页头”而是要考虑磨损均衡和垃圾回收。每个页在写满后会被标记为 full然后 NVS 会找一个 free 页做垃圾回收把有效数据搬过去擦除旧页。这个过程需要额外的空闲页作为缓冲一般建议至少保留 2 个空闲页。所以24KB 的 NVS 分区实际可用容量大概是6 个页每页 4KB保留 2 个空闲页用于垃圾回收4 个页用于数据每页约 126 个条目4096 / 32 - 1 页头每个条目平均存 32 字节数据总共约 16KB 有效数据如果你有 3 个应用每个应用要存 20 个配置项每个配置项平均 50 字节那就是 3 × 20 × 50 3000 字节看起来够。但 NVS 的条目有跨度概念一个 200 字节的字符串会占用多个条目实际占用会膨胀 2-3 倍。所以我的经验是多应用共用 NVS 时分区大小至少给 0x1000064KB如果应用数量超过 3 个或者配置项较多直接给 0x20000128KB。分区表里改大小很简单nvs, data, nvs, 0x9000, 0x10000,但要注意改大之后后面的分区偏移要相应调整否则会重叠。这就是为什么我强烈建议用脚本自动生成分区表而不是手写。4. 文件系统分区SPIFFS、LittleFS 和 FAT 的隔离差异4.1 三种文件系统的元数据布局对比当多个应用需要存文件比如日志、网页资源、模型文件时文件系统分区就登场了。ESP-IDF 支持 SPIFFS、LittleFS、FATFS 三种它们的元数据布局和隔离特性差别很大文件系统元数据位置擦除粒度多应用共用风险适用场景SPIFFS每个块头部4KB 块高无目录隔离小文件、只读资源LittleFS超级块 元数据对4KB 块中支持目录读写频繁的配置FATFSFAT 表 目录项512B 扇区低标准目录结构大文件、与 PC 交换SPIFFS 的问题是没有真正的目录结构所有文件都在一个扁平空间里文件名就是路径。如果你两个应用都往 SPIFFS 根目录写config.json后写的会覆盖先写的。而且 SPIFFS 的垃圾回收是全局的一个应用删除文件可能触发整个分区的 GC影响另一个应用的读写性能。LittleFS 支持目录隔离性好一些。你可以给每个应用分配一个目录// app_a 挂载到 /littlefs然后操作 /littlefs/app_a/ esp_vfs_littlefs_conf_t conf { .base_path /littlefs, .partition_label storage, .format_if_mount_failed false, .dont_mount false, }; esp_vfs_littlefs_register(conf); // 写文件 FILE *f fopen(/littlefs/app_a/config.json, w);但 LittleFS 的挂载是整个分区挂载两个应用如果都调用esp_vfs_littlefs_register()挂载同一个分区第二次会失败因为已经挂载了。正确的做法是只有一个应用负责挂载其他应用通过 VFS 路径访问。或者如果两个应用是轮流启动的OTA 场景那每个应用启动时挂载一次卸载时反注册不会冲突。FATFS 的隔离性最好因为它有标准的 FAT 表和目录项不同目录下的文件完全独立。但 FATFS 的缺点是掉电容易损坏而且需要额外的磨损均衡层ESP-IDF 的 FATFS 默认不带 wear leveling。如果多应用频繁写 FATFS建议加上wear_levelling组件esp_vfs_fat_mount_config_t mount_config { .format_if_mount_failed false, .max_files 5, .allocation_unit_size 4096, }; esp_vfs_fat_spiflash_mount_rw_wl(/fatfs, storage, mount_config, s_wl_handle);4.2 文件系统分区的“隐藏成本”很多人不知道文件系统分区在挂载时会在 RAM 里缓存元数据。SPIFFS 会缓存整个文件索引表LittleFS 会缓存目录项FATFS 会缓存 FAT 表的一部分。如果分区很大比如 1MB这个缓存可能占用几十 KB 的 RAM。ESP32 的 RAM 本来就紧张多应用共用时如果每个应用都挂载一次文件系统RAM 会迅速耗尽。我的做法是文件系统分区只挂载一次由主应用负责其他应用通过 IPC 或共享内存访问。如果做不到那就把文件系统分区拆小每个应用一个独立的小分区比如 64KB虽然浪费一些 Flash但 RAM 占用可控。另外文件系统的格式化操作是全局的。esp_littlefs_format()会擦除整个分区所有应用的文件全丢。所以格式化只能由系统级应用触发业务应用绝对不能调用。4.3 一个实用的目录隔离方案如果你确实需要多个应用共用一个文件系统分区我推荐用“应用 ID 目录”方案/storage/ /app_a/ config.json log.txt /app_b/ config.json data.bin /sys/ device_id.txt calibration.bin每个应用只能操作自己的目录代码里做路径前缀校验bool is_path_allowed(const char *path, const char *app_id) { char prefix[64]; snprintf(prefix, sizeof(prefix), /storage/%s/, app_id); return strncmp(path, prefix, strlen(prefix)) 0; }这个方案看起来简单但实际能挡住 90% 的误操作。我见过太多项目因为没做路径校验一个应用的 bug 把整个分区的文件删光。5. 当 WASM 虚拟机加入战局逻辑应用与物理存储的映射5.1 WASM 在 ESP32 上的存储访问模型最近两年在 ESP32 上跑 WASM 虚拟机做“逻辑小应用”的方案越来越流行。WASM 模块本身是存在 Flash 里的通常放在 SPIFFS 或 LittleFS 分区运行时由虚拟机加载到 RAM 执行。WASM 模块访问存储的方式通常有两种第一种是宿主函数host function。WASM 模块通过导入的函数调用宿主提供的存储 API比如host_nvs_read(key)、host_nvs_write(key, value)。这种模式下隔离完全由宿主控制——宿主可以在调用时自动加上应用 ID 前缀WASM 模块根本不知道底层是 NVS 还是文件系统。第二种是直接内存映射。WASM 模块通过线性内存访问宿主映射的 Flash 区域。这种模式下如果映射区域重叠WASM 模块之间就会串门。而且 WASM 的线性内存是沙箱化的但宿主映射的 Flash 区域如果没做边界检查WASM 模块可以通过越界访问读到其他应用的数据。我的建议是在 ESP32 这种资源受限的平台上WASM 模块一律走宿主函数访问存储不要做直接内存映射。宿主函数里做三件事根据当前运行的 WASM 模块 ID自动拼接存储 key 前缀校验访问权限只读/读写限制单次读写大小防止 WASM 模块申请超大 buffer 耗尽 RAM5.2 WASM 模块的存储配额管理多个 WASM 模块共用 NVS 或文件系统时最大的风险是一个模块写爆存储。NVS 分区写满后所有模块的写入都会失败文件系统分区写满后日志和配置都存不下。所以必须做配额管理。NVS 本身不支持配额但你可以用“命名空间 key 计数”来间接实现。比如每个 WASM 模块的命名空间下最多允许 50 个 key每个 key 的 value 不超过 512 字节。宿主函数在写入前检查esp_err_t wasm_nvs_write(const char *module_id, const char *key, const void *value, size_t len) { if (len 512) return ESP_ERR_INVALID_SIZE; char ns[16]; snprintf(ns, sizeof(ns), wasm_%s, module_id); nvs_handle_t handle; esp_err_t err nvs_open(ns, NVS_READWRITE, handle); if (err ! ESP_OK) return err; // 检查 key 数量 nvs_iterator_t it NULL; esp_err_t res nvs_entry_find(nvs, ns, NVS_TYPE_ANY, it); int count 0; while (res ESP_OK) { count; res nvs_entry_next(it); } nvs_release_iterator(it); if (count 50) { nvs_close(handle); return ESP_ERR_NVS_NOT_ENOUGH_SPACE; } err nvs_set_blob(handle, key, value, len); if (err ESP_OK) err nvs_commit(handle); nvs_close(handle); return err; }文件系统的配额可以用目录大小统计来实现但更简单的方法是给每个 WASM 模块分配独立的文件系统分区。虽然分区表会多几个条目但隔离性最好而且每个分区可以独立格式化不影响其他模块。5.3 WASM 模块更新时的存储迁移WASM 模块更新比如从 v1 升级到 v2时存储的数据结构可能变化。如果直接覆盖新模块可能读不懂旧数据。我的做法是在 NVS 里存一个 schema 版本号模块启动时检查版本不匹配就触发迁移或重置。uint32_t schema_ver 0; nvs_get_u32(handle, schema_ver, schema_ver); if (schema_ver ! EXPECTED_SCHEMA_VER) { // 迁移逻辑读取旧 key转换后写入新 key // 或者直接擦除命名空间让模块重新初始化 nvs_erase_all(handle); nvs_set_u32(handle, schema_ver, EXPECTED_SCHEMA_VER); nvs_commit(handle); }这个机制看起来简单但能避免大量“升级后配置错乱”的问题。我建议所有多应用共用的存储都加上 schema 版本管理成本很低收益很大。6. 排查数据串门的完整链路从现象到根因6.1 第一步确认串门发生在哪一层数据串门的现象很多但排查思路可以统一先定位是物理层、逻辑层还是缓存层的问题。物理层串门表现为“一个应用写数据另一个应用的数据损坏或丢失”。排查方法是读分区表检查两个应用的存储区域是否有扇区重叠。用esptool.py read_flash把整个 Flash 读出来对比写入前后的差异看哪些扇区被意外擦除。逻辑层串门表现为“两个应用读到对方的数据但数据本身没损坏”。排查方法是检查 NVS 命名空间是否重复、文件系统路径是否冲突、key 名是否相同。缓存层串门表现为“写入后立即读读到旧数据重启后读数据正确”。排查方法是检查是否有 mmap 映射的 Flash 区域被运行时擦写以及 cache 失效操作是否到位。6.2 第二步用 NVS 的 dump 工具看真实数据ESP-IDF 提供了一个nvs_tool.py可以解析 NVS 分区并打印所有命名空间和 keypython $IDF_PATH/components/nvs_flash/nvs_partition_tool/nvs_tool.py \ --partition build/partition_table/partition-table.bin \ --nvs_partition build/nvs.bin \ dump输出会列出每个命名空间的 ID、名字、以及所有 key-value。如果你怀疑两个应用串门用这个工具一看就知道如果两个应用的数据出现在同一个命名空间下那就是代码里命名空间用错了如果命名空间不同但 key 名相同那就是逻辑设计问题。6.3 第三步检查分区表的对齐和重叠分区表的重叠问题用肉眼很难发现因为偏移都是十六进制。我写了一个简单的 Python 脚本来自动检查import struct def parse_partition_table(path): partitions [] with open(path, rb) as f: data f.read() for i in range(0, len(data), 32): entry data[i:i32] if len(entry) 32: break magic struct.unpack(H, entry[0:2])[0] if magic ! 0x50AA: continue ptype, subtype entry[2], entry[3] offset, size struct.unpack(II, entry[4:12]) name entry[12:28].rstrip(b\x00).decode(utf-8) partitions.append((name, offset, size)) return partitions def check_overlap(partitions): sorted_parts sorted(partitions, keylambda x: x[1]) for i in range(len(sorted_parts) - 1): name1, off1, size1 sorted_parts[i] name2, off2, size2 sorted_parts[i1] if off1 size1 off2: print(fOVERLAP: {name1} (0x{off1:x}0x{size1:x}) foverlaps {name2} (0x{off2:x})) if off2 % 0x1000 ! 0: print(fALIGNMENT: {name2} offset 0x{off2:x} not 4KB aligned)这个脚本在 CI 里跑一次能挡住 99% 的分区表错误。6.4 第四步运行时监控 Flash 擦写如果串门是偶发的静态检查发现不了那就需要运行时监控。ESP32 的 SPI Flash 驱动提供了esp_flash_erase_region()和esp_flash_write()的钩子但默认不暴露。你可以通过重写spi_flash_hal_erase或者用esp_flash_app_disable_os_functions来拦截。更简单的方法是在 NVS 和文件系统的写入路径上加日志// 在 nvs_set_blob 之前打印调用栈 ESP_LOGI(TAG, NVS write: ns%s key%s len%d, ns, key, len);如果日志里出现了一个应用写了另一个应用的命名空间那就直接定位到了。7. 一套可落地的多应用存储隔离方案7.1 分区表设计预留足够的隔离空间基于上面的分析我给一个实际项目用的分区表模板4MB Flash# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x10000, otadata, data, ota, 0x19000, 0x2000, phy_init, data, phy, 0x1B000, 0x1000, factory, app, factory, 0x20000, 0x1C0000, ota_0, app, ota_0, 0x1E0000, 0x1C0000, storage, data, spiffs, 0x3A0000, 0x40000, wasm_a, data, spiffs, 0x3E0000, 0x10000, wasm_b, data, spiffs, 0x3F0000, 0x10000,关键设计点nvs 给 64KB足够 3-5 个应用共用每个应用一个命名空间。storage 给 256KB用于共享文件日志、网页资源按目录隔离。wasm_a 和 wasm_b 各 64KB每个 WASM 模块独立文件系统分区彻底隔离。所有分区 4KB 对齐app 分区 64KB 对齐。7.2 代码层的访问控制清单分区表只是基础代码层还要做这些NVS 访问统一封装所有 NVS 读写走一个封装函数自动加应用前缀禁止直接调用nvs_open。文件系统路径校验所有文件操作前检查路径前缀禁止跨应用目录访问。WASM 宿主函数做配额限制每个模块的 key 数量和 value 大小。OTA 升级时保留数据ota_0 和 ota_1 共用 nvs 和 storage升级不擦除数据分区。恢复出厂设置分级支持“只擦应用数据”和“全擦”两种模式。7.3 实测中的三个意外情况第一个意外NVS 的nvs_flash_init()在 OTA 后返回ESP_ERR_NVS_NO_FREE_PAGES。原因是 OTA 升级后新固件往 NVS 写了新 key但旧 key 没删页用完了。解决方法是捕获这个错误调用nvs_flash_erase()后重新初始化。但注意这会擦除所有命名空间的数据所以要在升级前做好数据迁移。第二个意外LittleFS 挂载失败后自动格式化把另一个应用的数据擦了。esp_vfs_littlefs_register()的format_if_mount_failed参数如果设为true挂载失败时会自动格式化整个分区。多应用共用时这个参数必须设为false否则一个应用的挂载失败会连累另一个应用。第三个意外WASM 模块的线性内存越界访问读到了宿主数据。WASM 虚拟机本身有沙箱但如果宿主函数返回的指针指向了共享内存区域WASM 模块可以通过指针运算越界读取。解决方法是在宿主函数里做深拷贝返回独立的内存块而不是直接返回共享内存指针。8. 几个能直接抄的配置和代码片段8.1 NVS 命名空间封装// nvs_wrapper.h esp_err_t app_nvs_open(const char *app_id, nvs_handle_t *handle); esp_err_t app_nvs_set_str(const char *app_id, const char *key, const char *value); esp_err_t app_nvs_get_str(const char *app_id, const char *key, char *value, size_t *len); // nvs_wrapper.c esp_err_t app_nvs_open(const char *app_id, nvs_handle_t *handle) { char ns[16]; snprintf(ns, sizeof(ns), app_%s, app_id); return nvs_open(ns, NVS_READWRITE, handle); }8.2 文件系统路径校验static const char *ALLOWED_PREFIX /storage/app_a/; esp_err_t safe_file_write(const char *path, const void *data, size_t len) { if (strncmp(path, ALLOWED_PREFIX, strlen(ALLOWED_PREFIX)) ! 0) { ESP_LOGE(TAG, path %s not allowed, path); return ESP_ERR_INVALID_ARG; } FILE *f fopen(path, wb); if (!f) return ESP_FAIL; fwrite(data, 1, len, f); fclose(f); return ESP_OK; }8.3 分区表自动校验脚本# check_partition.py import subprocess import sys def main(): result subprocess.run( [python, gen_esp32part.py, --verify, build/partition_table/partition-table.bin], capture_outputTrue, textTrue ) if result.returncode ! 0: print(Partition table verification failed:) print(result.stderr) sys.exit(1) print(Partition table OK) if __name__ __main__: main()把这个脚本加到CMakeLists.txt的add_custom_target里每次构建自动跑。8.4 WASM 宿主函数配额检查#define MAX_KEYS_PER_MODULE 50 #define MAX_VALUE_SIZE 512 esp_err_t wasm_storage_write(const char *module_id, const char *key, const void *value, size_t len) { if (len MAX_VALUE_SIZE) return ESP_ERR_INVALID_SIZE; char ns[16]; snprintf(ns, sizeof(ns), wasm_%s, module_id); nvs_handle_t handle; esp_err_t err nvs_open(ns, NVS_READWRITE, handle); if (err ! ESP_OK) return err; // 检查 key 数量 nvs_iterator_t it NULL; esp_err_t res nvs_entry_find(nvs, ns, NVS_TYPE_ANY, it); int count 0; while (res ESP_OK) { count; res nvs_entry_next(it); } nvs_release_iterator(it); if (count MAX_KEYS_PER_MODULE) { nvs_close(handle); return ESP_ERR_NVS_NOT_ENOUGH_SPACE; } err nvs_set_blob(handle, key, value, len); if (err ESP_OK) err nvs_commit(handle); nvs_close(handle); return err; }9. 最后分享几个我在实际项目里踩出来的经验经验一NVS 的 key 名不要用中文或特殊字符。NVS 的 key 最大 15 字符而且只支持 ASCII 可见字符。我见过有人用配置做 key编译能过运行时nvs_set_str返回ESP_ERR_NVS_INVALID_LENGTH查了半天才发现是编码问题。统一用英文小写加下划线比如wifi_ssid、mqtt_broker。经验二文件系统的挂载点不要用根目录。esp_vfs_littlefs_register()的base_path如果设为/会覆盖整个 VFS 根导致其他文件系统无法挂载。统一用/storage、/wasm_a这种独立前缀。经验三OTA 升级前先备份 NVS。虽然 OTA 本身不擦除 NVS但如果新固件有 bug 导致 NVS 写坏回滚后旧固件也读不了。我的做法是在 OTA 前把关键配置导出到 storage 分区的一个文件里升级后如果 NVS 异常从文件恢复。经验四多应用共用 Flash 时永远不要假设“另一个应用不会写我的区域”。所有跨应用的数据访问都要走明确的接口接口里做校验和日志。我现在的项目里每个存储操作都会打印app_id、namespace、key、operation出问题时看日志就能定位。经验五Flash 的擦写寿命是 10 万次左右多应用共用时磨损会集中。如果某个应用频繁写 NVS比如每秒写一次传感器数据那个扇区会很快磨损。解决办法是用 RAM 缓存 定时批量写入或者把高频数据写到文件系统有磨损均衡NVS 只存低频配置。这套方案我在三个量产项目里用过最长的已经跑了两年多没有出现过数据串门的问题。核心就是一句话物理上分扇区逻辑上分命名空间访问上做校验升级时做迁移。把这四件事做到位多应用共用一块 Flash 就不是什么难题。
