1. 一块 Flash 上跑多个应用数据隔离到底难在哪ESP32 这类芯片的 Flash 通常只有 4MB 到 16MB实际项目里往往不止一个应用在跑。比如一个设备上同时有传感器采集任务、Web 配置页面、OTA 升级模块、蓝牙配网服务甚至还有跑在 WASM 虚拟机里的第三方小应用。这些模块都要读写 Flash 来保存配置、缓存数据、记录日志如果没有任何隔离机制A 应用写的数据被 B 应用覆盖或者 C 应用读到了 D 应用的敏感信息整个系统就会变得不可靠。这个问题的本质是共享存储介质的并发访问与命名空间隔离。Flash 不像内存那样可以随意分配释放它有擦写寿命限制、有扇区对齐要求、有掉电丢失风险。多个应用共用一块 Flash需要解决三个层面的问题物理层面的分区划分、逻辑层面的键值命名空间隔离、以及运行时的并发访问控制。我见过不少项目在这块踩坑。有个做智能家居网关的团队主应用把 Wi-Fi 配置存在 NVS 的wifi_config命名空间里后来加了一个蓝牙配网模块也用了同样的命名空间和键名结果蓝牙配网写入的临时凭证把主应用的正式配置覆盖了设备重启后直接连不上路由器。这种问题在开发阶段很难发现因为两个模块单独测试都正常只有同时运行才会暴露。注意ESP32 的 Flash 分区一旦烧录就不能随意改动分区表的设计要在项目初期就规划好后期调整意味着所有设备都要重新烧录OTA 升级也无法解决分区表变更的问题。适合阅读这篇内容的人包括正在做 ESP32 多应用项目的嵌入式开发者、需要在一块 Flash 上管理多个数据域的物联网产品经理、以及遇到 NVS 数据冲突问题的调试人员。下面我会从分区设计、NVS 命名空间、WASM 沙箱存储、并发控制几个角度把这块 Flash 上的“分家”问题讲透。2. 分区表设计给每个应用划一块自留地2.1 为什么不能所有应用共用一个分区ESP32 的 Flash 默认分区表通常包含nvs、phy_init、factory、ota_0、ota_1等区域。很多开发者拿到开发板后直接往nvs分区里塞所有数据觉得反正 NVS 是键值存储不同应用用不同键名就行了。这个思路在小项目里能跑通但一旦应用数量超过三个就会出现几个致命问题。第一NVS 分区默认大小通常是 0x500020KB或 0x600024KB这个容量对于单个应用存配置够用但多个应用同时写入日志、缓存、用户数据时很容易写满。NVS 写满后的行为是返回ESP_ERR_NVS_NOT_ENOUGH_SPACE如果应用没有处理这个错误数据就会静默丢失。第二NVS 的键值对是按命名空间组织的但命名空间本身没有权限控制。任何应用只要知道命名空间名称就能读写里面的数据。这意味着一个跑在 WASM 虚拟机里的第三方应用如果知道了主应用的命名空间就能直接读取 Wi-Fi 密码。第三NVS 的擦写操作会影响整个分区。当某个应用频繁写入数据导致 NVS 页面需要垃圾回收时会阻塞其他应用对同一分区的访问造成实时性下降。所以正确的做法是给每个需要独立存储的应用分配单独的分区。ESP32 的分区表最多支持 16 个分区足够大多数项目使用。2.2 自定义分区表的实操写法分区表是一个 CSV 文件通常命名为partitions.csv放在项目根目录下。下面是一个支持多应用隔离的分区表示例# 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, 0x140000, ota_0, app, ota_0, 0x150000,0x140000, ota_1, app, ota_1, 0x290000,0x140000, app1_nvs, data, nvs, 0x3d0000,0x4000, app2_nvs, data, nvs, 0x3d4000,0x4000, wasm_fs, data, spiffs, 0x3d8000,0x10000,这里有几个关键点。app1_nvs和app2_nvs是两个独立的 NVS 分区各自有 16KB 空间。wasm_fs是一个 SPIFFS 分区专门给 WASM 虚拟机里的应用做文件存储。每个分区的 Offset 必须按 0x10004KB对齐这是 Flash 扇区大小的硬性要求。在代码中应用通过分区名称来获取对应的 NVS 句柄// 应用1初始化自己的NVS esp_err_t err nvs_flash_init_partition(app1_nvs); if (err ESP_ERR_NVS_NO_FREE_PAGES || err ESP_ERR_NVS_NEW_VERSION_FOUND) { ESP_ERROR_CHECK(nvs_flash_erase_partition(app1_nvs)); err nvs_flash_init_partition(app1_nvs); } nvs_handle_t handle1; nvs_open_from_partition(app1_nvs, config, NVS_READWRITE, handle1); // 应用2初始化自己的NVS nvs_flash_init_partition(app2_nvs); nvs_handle_t handle2; nvs_open_from_partition(app2_nvs, config, NVS_READWRITE, handle2);这样应用1和应用2的存储完全隔离即使键名相同也不会冲突。应用1无法访问app2_nvs分区除非它显式调用nvs_flash_init_partition(app2_nvs)而我们可以通过代码审查或权限控制来禁止这种行为。2.3 分区大小怎么估算分区大小不是拍脑袋定的。NVS 分区的容量估算有一个经验公式每个键值对大约占用 32 字节的元数据加上实际数据长度。如果应用需要存储 100 个配置项平均每个配置项 64 字节那么总需求是 100 × (32 64) 9600 字节加上垃圾回收的冗余空间建议分配 16KB 到 24KB。SPIFFS 分区用于文件存储时需要考虑文件数量和平均文件大小。SPIFFS 的元数据开销大约是每个文件 32 字节每个数据页 256 字节。如果 WASM 应用需要存储 50 个文件平均每个 2KB那么总需求是 50 × (32 2048) ≈ 104KB建议分配 128KB 以上。实操心得分区表一旦确定后期修改需要重新烧录整个 FlashOTA 升级无法更新分区表。所以在项目初期就要预留足够的空间宁可多分一点也不要后期返工。我通常会在估算值的基础上乘以 1.5 作为安全系数。3. NVS 命名空间同一分区内的逻辑隔离3.1 命名空间的实际作用与限制如果两个应用必须共用一个 NVS 分区比如 Flash 空间实在紧张那么命名空间就是最后一道防线。NVS 的命名空间是一个字符串标识最长 15 个字符同一个分区内可以有多个命名空间每个命名空间下的键名独立。// 应用A使用命名空间 app_a nvs_open_from_partition(shared_nvs, app_a, NVS_READWRITE, handle_a); nvs_set_str(handle_a, wifi_ssid, MyNetwork); nvs_commit(handle_a); // 应用B使用命名空间 app_b nvs_open_from_partition(shared_nvs, app_b, NVS_READWRITE, handle_b); nvs_set_str(handle_b, wifi_ssid, AnotherNetwork); nvs_commit(handle_b);两个应用都写了wifi_ssid这个键但因为命名空间不同数据不会互相覆盖。读取时也必须指定正确的命名空间size_t len 32; char ssid[32]; nvs_get_str(handle_a, wifi_ssid, ssid, len); // 读到 MyNetwork但命名空间的限制也很明显。首先命名空间名称是明文存储在 Flash 中的任何能读取 Flash 原始数据的工具都能看到所有命名空间名称。其次NVS 没有提供命名空间级别的访问控制应用A只要知道应用B的命名空间名称就能打开并读写。最后命名空间数量过多会导致 NVS 页面碎片化降低存储效率。3.2 命名空间命名规范与冲突避免在实际项目中我建议采用统一的命名规范来避免冲突。比如用应用ID加模块名的方式app1_cfg、app1_log、app2_cfg、app2_cache。这样即使多个应用共用一个分区也能通过命名空间前缀快速识别归属。更重要的是要在代码层面做一层封装禁止应用直接调用nvs_open_from_partition。可以提供一个存储服务层每个应用注册时分配一个唯一的命名空间前缀所有读写操作都经过这层服务typedef struct { char namespace_prefix[16]; nvs_handle_t handle; } storage_ctx_t; esp_err_t storage_init(storage_ctx_t *ctx, const char *app_id) { snprintf(ctx-namespace_prefix, sizeof(ctx-namespace_prefix), %s_cfg, app_id); return nvs_open_from_partition(shared_nvs, ctx-namespace_prefix, NVS_READWRITE, ctx-handle); } esp_err_t storage_set_str(storage_ctx_t *ctx, const char *key, const char *value) { return nvs_set_str(ctx-handle, key, value); }这样应用只能通过storage_set_str写入自己的命名空间无法越界访问。虽然这层封装不能防止恶意代码直接调用底层 API但对于正常的模块化开发已经足够。3.3 NVS 加密与安全增强如果应用涉及敏感数据比如 Wi-Fi 密码、API 密钥、用户令牌那么 NVS 加密是必须的。ESP32 支持 Flash 加密和 NVS 加密两种机制。Flash 加密是对整个 Flash 内容进行加密包括代码和数据NVS 加密是单独对 NVS 分区进行加密密钥存储在 eFuse 中。启用 NVS 加密后即使攻击者通过物理方式读取了 Flash 芯片也无法解密 NVS 中的数据。配置方法是在menuconfig中开启CONFIG_SECURE_FLASH_ENC_ENABLED和CONFIG_SECURE_NVS_ENCRYPTION然后重新烧录。注意启用 Flash 加密后首次烧录需要生成加密密钥并烧写到 eFuse 中这个过程是不可逆的。一旦 eFuse 被烧写芯片就只能运行加密后的固件。所以在开发阶段不要轻易启用等产品定型后再操作。4. WASM 虚拟机的存储沙箱设计4.1 WASM 应用为什么需要独立存储WASM 在 ESP32 上跑通常是为了让第三方开发者能够用 C、Rust 或 AssemblyScript 写小应用然后动态加载到设备上运行。这些 WASM 应用可能来自不同的开发者彼此之间不应该共享存储空间。如果 WASM 应用 A 能读取 WASM 应用 B 的配置文件就会造成隐私泄露和安全风险。ESP32 上常用的 WASM 运行时包括 Wasm3、WAMRWebAssembly Micro Runtime和 WasmEdge。这些运行时本身不提供存储隔离需要我们在宿主层面实现。我的做法是给每个 WASM 应用分配一个独立的 SPIFFS 分区或一个独立的 NVS 命名空间然后通过宿主函数host function暴露有限的存储 API 给 WASM 应用。4.2 宿主函数实现存储隔离WASM 应用不能直接调用 ESP-IDF 的 NVS API而是通过导入的宿主函数来间接访问。下面是一个简化的实现// 宿主函数WASM应用写入数据 m3ApiRawFunction(host_storage_write) { m3ApiGetArgMem(const uint8_t *, key_ptr); m3ApiGetArg(uint32_t, key_len); m3ApiGetArgMem(const uint8_t *, value_ptr); m3ApiGetArg(uint32_t, value_len); // 根据当前WASM应用的ID选择对应的NVS命名空间 nvs_handle_t handle; nvs_open_from_partition(wasm_nvs, current_wasm_app_id, NVS_READWRITE, handle); char key[32]; memcpy(key, key_ptr, key_len); key[key_len] \0; nvs_set_blob(handle, key, value_ptr, value_len); nvs_commit(handle); nvs_close(handle); m3ApiReturnType(uint32_t); m3ApiReturn(0); // 返回成功 }current_wasm_app_id是宿主在加载 WASM 模块时设置的全局变量每个 WASM 应用有唯一的 ID。这样即使两个 WASM 应用都调用host_storage_write写入相同的键名数据也会落在不同的命名空间中。4.3 存储配额与生命周期管理WASM 应用的存储还需要考虑配额和生命周期。一个恶意或低质量的 WASM 应用可能不断写入数据直到 Flash 写满影响其他应用。所以宿主需要限制每个 WASM 应用的存储配额。实现方式是在宿主层维护一个计数器记录每个 WASM 应用已使用的字节数。每次写入前检查是否超过配额#define WASM_APP_MAX_STORAGE 4096 // 每个WASM应用最多4KB static size_t wasm_app_usage[MAX_WASM_APPS]; esp_err_t wasm_storage_write(const char *app_id, const char *key, const void *value, size_t len) { int app_idx find_app_index(app_id); if (wasm_app_usage[app_idx] len WASM_APP_MAX_STORAGE) { return ESP_ERR_NO_MEM; // 超出配额 } // 执行写入... wasm_app_usage[app_idx] len; return ESP_OK; }当 WASM 应用被卸载时宿主应该清理其对应的 NVS 命名空间释放存储空间。这可以通过nvs_erase_all实现void wasm_app_unload(const char *app_id) { nvs_handle_t handle; if (nvs_open_from_partition(wasm_nvs, app_id, NVS_READWRITE, handle) ESP_OK) { nvs_erase_all(handle); nvs_commit(handle); nvs_close(handle); } }实操心得WASM 应用的存储清理一定要在卸载时同步执行否则残留数据会占用 Flash 空间。我遇到过因为卸载逻辑有 bug导致 20 个 WASM 应用卸载后残留了 80KB 数据的情况最后只能通过擦除整个 wasm_nvs 分区来解决。5. 并发访问控制与掉电保护5.1 多任务同时写 Flash 的冲突场景ESP32 是双核处理器通常跑 FreeRTOS多个任务可能同时访问 Flash。NVS 本身提供了一定的线程安全机制通过互斥锁保护内部数据结构。但跨分区的操作没有全局锁如果任务 A 在写app1_nvs任务 B 在写app2_nvs两者可以并行执行这没问题。问题出在同一个分区被多个任务同时写入时。NVS 的nvs_set_*和nvs_commit是两步操作。如果任务 A 调用了nvs_set_str但还没调用nvs_commit任务 B 也调用了nvs_set_str那么任务 B 的写入可能会覆盖任务 A 的未提交数据。虽然 NVS 内部有锁保护单次 API 调用但跨 API 调用的原子性需要应用层自己保证。解决方案是在应用层加互斥锁static SemaphoreHandle_t nvs_mutex NULL; void storage_init_mutex(void) { nvs_mutex xSemaphoreCreateMutex(); } esp_err_t storage_safe_write(nvs_handle_t handle, const char *key, const char *value) { if (xSemaphoreTake(nvs_mutex, pdMS_TO_TICKS(1000)) ! pdTRUE) { return ESP_ERR_TIMEOUT; } esp_err_t err nvs_set_str(handle, key, value); if (err ESP_OK) { err nvs_commit(handle); } xSemaphoreGive(nvs_mutex); return err; }这个锁的粒度是分区级别的不同分区可以用不同的锁避免不必要的阻塞。5.2 掉电保护与数据完整性Flash 写入过程中如果掉电可能导致数据损坏。NVS 本身有一定的掉电保护机制它使用日志结构存储每次写入都是追加而不是覆盖掉电后可以通过日志恢复。但 SPIFFS 的掉电保护就弱一些特别是文件正在写入时掉电可能导致文件系统损坏。对于关键数据我建议采用双备份加校验的方式。比如 Wi-Fi 配置同时写入app1_nvs的config命名空间和config_backup命名空间读取时先读主配置如果校验失败再读备份typedef struct { char ssid[32]; char password[64]; uint32_t crc32; } wifi_config_t; esp_err_t save_wifi_config(const wifi_config_t *cfg) { wifi_config_t cfg_with_crc *cfg; cfg_with_crc.crc32 crc32_le(0, (uint8_t *)cfg, sizeof(wifi_config_t) - 4); // 写入主配置 nvs_set_blob(handle, wifi_main, cfg_with_crc, sizeof(wifi_config_t)); // 写入备份配置 nvs_set_blob(handle, wifi_backup, cfg_with_crc, sizeof(wifi_config_t)); return nvs_commit(handle); } esp_err_t load_wifi_config(wifi_config_t *cfg) { size_t len sizeof(wifi_config_t); esp_err_t err nvs_get_blob(handle, wifi_main, cfg, len); if (err ESP_OK) { uint32_t crc crc32_le(0, (uint8_t *)cfg, sizeof(wifi_config_t) - 4); if (crc cfg-crc32) { return ESP_OK; // 主配置有效 } } // 主配置无效读备份 len sizeof(wifi_config_t); err nvs_get_blob(handle, wifi_backup, cfg, len); if (err ESP_OK) { uint32_t crc crc32_le(0, (uint8_t *)cfg, sizeof(wifi_config_t) - 4); if (crc cfg-crc32) { return ESP_OK; // 备份有效 } } return ESP_ERR_INVALID_CRC; }5.3 Flash 寿命管理与磨损均衡ESP32 的 Flash 擦写寿命通常是 10 万次左右。如果某个应用频繁写入同一个键比如每秒记录一次传感器数据那么 Flash 很快就会损坏。NVS 内部有一定的磨损均衡机制但它是在页面级别工作的如果数据量很小但写入频率很高磨损均衡效果有限。对于高频写入场景我建议采用以下几种策略。第一使用 RAM 缓存加定期刷写比如每 5 分钟或每 100 条数据才写入一次 Flash。第二使用环形缓冲区把数据分散到不同的 Flash 区域避免集中擦写。第三对于日志类数据考虑使用外部 SD 卡或通过 Wi-Fi 上传到服务器减少本地 Flash 写入。下面是一个简单的写入频率控制示例#define WRITE_INTERVAL_MS 300000 // 5分钟 static uint32_t last_write_time 0; static char pending_data[256]; static bool has_pending false; void sensor_data_update(const char *data) { strncpy(pending_data, data, sizeof(pending_data) - 1); has_pending true; } void storage_task(void *arg) { while (1) { uint32_t now xTaskGetTickCount() * portTICK_PERIOD_MS; if (has_pending (now - last_write_time WRITE_INTERVAL_MS)) { nvs_set_str(handle, sensor_log, pending_data); nvs_commit(handle); last_write_time now; has_pending false; } vTaskDelay(pdMS_TO_TICKS(1000)); } }注意NVS 的nvs_commit是实际写入 Flash 的操作nvs_set_*只是写入 RAM 缓存。如果不调用nvs_commit数据不会持久化。但频繁调用nvs_commit会增加 Flash 磨损所以要平衡实时性和寿命。6. 常见问题与排查技巧实录6.1 NVS 初始化失败与分区表错误最常见的错误是ESP_ERR_NVS_NO_FREE_PAGES这通常意味着 NVS 分区已满或分区表配置错误。排查步骤是首先检查分区表中 NVS 分区的大小是否足够其次检查是否有应用在疯狂写入数据导致分区写满最后检查分区偏移是否与其他分区重叠。如果出现ESP_ERR_NVS_PART_NOT_FOUND说明分区表中没有对应的分区名称。这时候要用idf.py partition-table命令查看当前分区表确认分区名称拼写是否正确。还有一个隐蔽的问题是分区表版本不匹配。ESP-IDF 不同版本对分区表的格式要求略有差异如果从旧版本升级到新版本可能需要重新生成分区表。6.2 数据串门的典型场景与修复数据串门最典型的表现是应用 A 保存了配置重启后读出来的是应用 B 的数据。这种情况通常是命名空间或分区名称写错了。排查方法是打印所有 NVS 命名空间和键值void dump_nvs_partition(const char *part_name) { nvs_iterator_t it NULL; esp_err_t res nvs_entry_find(part_name, NULL, NVS_TYPE_ANY, it); while (res ESP_OK) { nvs_entry_info_t info; nvs_entry_info(it, info); ESP_LOGI(NVS_DUMP, namespace%s, key%s, type%d, info.namespace_name, info.key, info.type); res nvs_entry_next(it); } nvs_release_iterator(it); }这个函数会列出指定分区中所有的命名空间和键方便对比实际存储与预期是否一致。另一个场景是 WASM 应用的宿主函数没有正确设置current_wasm_app_id导致所有 WASM 应用都写到了同一个命名空间。修复方法是确保在加载每个 WASM 模块时都更新这个全局变量并且在 WASM 应用调用存储 API 时再次校验。6.3 常见问题速查表问题现象可能原因排查方法解决方案NVS 初始化返回 NO_FREE_PAGES分区已满或碎片化调用nvs_get_stats查看使用情况擦除分区或扩大分区读取数据返回 INVALID_LENGTH键名错误或数据类型不匹配用nvs_entry_find列出所有键检查键名和类型数据写入后重启丢失未调用nvs_commit检查代码中是否有 commit 调用在写入后调用 commit两个应用数据互相覆盖共用命名空间或分区打印命名空间和键名分配独立分区或命名空间Flash 写入速度慢频繁 commit 或分区碎片化测量写入耗时减少 commit 频率或整理分区WASM 应用无法存储宿主函数未注册或配额超限检查宿主函数注册和配额计数注册函数或增加配额6.4 独家避坑技巧第一个技巧是在开发阶段启用 NVS 断言。在menuconfig中开启CONFIG_NVS_ASSERT_ERROR_CHECK这样任何 NVS API 返回错误都会触发断言而不是静默失败。这能帮你快速定位问题但在生产固件中要关闭避免设备崩溃。第二个技巧是给每个分区打上版本号。在 NVS 中存储一个partition_version键应用启动时检查版本号是否匹配。如果版本号不匹配说明分区表或数据结构发生了变化需要执行迁移逻辑。这能避免固件升级后数据结构不兼容的问题。第三个技巧是使用 NVS 的 blob 类型存储结构体。很多开发者喜欢把结构体的每个字段单独存为一个键这样不仅浪费空间还容易因为字段增减导致兼容性问题。直接把整个结构体作为 blob 存储配合版本号和 CRC 校验是更稳妥的做法。typedef struct { uint32_t version; char ssid[32]; char password[64]; uint32_t crc32; } app_config_t; // 存储 app_config_t cfg { .version 2, .ssid MyWiFi }; cfg.crc32 crc32_le(0, (uint8_t *)cfg, sizeof(cfg) - 4); nvs_set_blob(handle, config, cfg, sizeof(cfg)); // 读取 app_config_t loaded; size_t len sizeof(loaded); nvs_get_blob(handle, config, loaded, len); if (loaded.version ! 2) { // 执行版本迁移 }第四个技巧是定期监控 Flash 使用情况。在设备运行过程中定期调用nvs_get_stats获取已用条目数、可用条目数、命名空间数量等指标通过日志或上报到服务器。这样可以在 Flash 写满之前提前发现异常避免设备突然无法写入数据。nvs_stats_t stats; nvs_get_stats(app1_nvs, stats); ESP_LOGI(FLASH_MON, used%d, free%d, total%d, ns_count%d, stats.used_entries, stats.free_entries, stats.total_entries, stats.namespace_count);这套监控机制在我负责的一个项目中发挥了关键作用。有一次发现某个设备的free_entries在 24 小时内从 500 降到了 50排查后发现是一个日志模块的写入频率配置错误每秒写入了 10 条日志。如果没有监控设备可能在几天后就会因为 Flash 写满而停止工作。6.5 关于 WASM 存储的额外提醒WASM 应用在 ESP32 上跑存储性能是一个容易被忽视的瓶颈。WASM 的宿主函数调用有额外的开销每次存储操作都要经过 WASM 运行时、宿主函数、NVS 三层比原生代码直接调用 NVS 慢 3 到 5 倍。所以对于 WASM 应用更要强调批量写入和缓存策略。另外WASM 应用的内存是线性的宿主函数在传递数据时要注意内存边界检查。如果 WASM 应用传入的指针超出了它的线性内存范围宿主函数直接读取会导致崩溃。Wasm3 提供了m3ApiGetArgMem宏来做边界检查但 WAMR 需要手动验证指针范围。我在实际项目中遇到过 WASM 应用传入非法指针导致设备重启的问题后来在宿主函数入口加了指针范围校验才解决。这个坑花了两天才定位到因为崩溃日志只显示访问了非法地址没有说明是哪个 WASM 应用触发的。后来在每个宿主函数里加了应用 ID 的日志输出才快速定位到问题应用。存储隔离这件事说到底就是要在项目初期就把分区表、命名空间、访问控制这三层设计好。后期再改成本会成倍增加。我个人的经验是宁可多花两天做设计也不要后期花两周做迁移。
