企业官网建设流程全解析

1. 为什么要在微控制器上折腾一个“应用商店”

第一次跟朋友聊起这个想法的时候，对方的表情基本就是“你没事吧”。一个几十块钱的微控制器，Flash 撑死几兆，RAM 按几百 KB 算，跑个蓝牙加 Wi-Fi 协议栈就已经喘得不行了，还搞应用商店？这不是拿算盘去跑电商平台吗。

但真把这事拆开看，会发现“应用商店”这四个字在嵌入式语境里，跟手机上的那个庞然大物完全不是一回事。手机应用商店解决的是“几百万开发者给几亿用户分发几十万个 App”的问题，而微控制器上的应用商店，解决的是一个非常具体、非常土、但确实很痛的问题：同一块硬件，怎么在不重新烧录固件的前提下，换一套功能。

我做过不少基于 ESP32 的小项目，从环境监测节点到带屏的桌面小玩意都有。每次改功能，哪怕只是把“显示温度”改成“显示湿度”，都得插 USB 线、开 IDE、编译、烧录，一套流程下来五分钟起步。如果设备已经装在墙上、焊在盒子里、或者送给了不懂技术的朋友，这个流程直接变成灾难。应用商店这个思路，本质上是把“换功能”这件事从“重新烧固件”降级成“下载一个包然后加载”，这才是它真正的意义所在。

所以这篇文章不是要论证“ESP32 能不能跑应用商店”这种伪命题，而是想认真聊聊：在资源受限的微控制器上做应用分发，到底能解决什么真实需求，技术上怎么落地，以及哪些坑是必须提前知道的。适合手里有 ESP32、玩过 Arduino 或 ESP-IDF、想往“可扩展固件架构”方向走一步的人看。如果你只是想点个灯，那确实没必要往下读。

2. 先想清楚：这个“商店”到底要解决什么问题

2.1 三种典型场景，决定了架构走向

在动手写一行代码之前，得先明确你的应用商店服务于哪种场景。我见过的大多数尝试，最后失败的原因不是技术不行，而是一开始就没想清楚“给谁用”。

场景一：开发者自己的多设备管理。你手上有十几块 ESP32，分别做不同的事，有的当传感器网关，有的当显示屏驱动。你希望有一个统一的固件底座，然后按需加载不同功能模块。这种情况下，应用商店其实是一个“模块仓库”，用户就是你自己，不需要考虑权限、签名、回滚这些复杂机制。

场景二：面向非技术用户的设备。比如你做了一个基于 ESP32 的桌面小屏幕，送给朋友。朋友想换个时钟样式、加个天气显示，但不可能让他装 IDE。这时候应用商店就是一个“功能包下载器”，需要解决版本管理、依赖检查、失败回滚。

场景三：教学或实验平台。一块开发板发给学生，学生通过网页或手机 App 选择要运行的功能，比如“今天做温湿度采集”“明天做红外遥控解码”。这种情况下，应用商店更像一个“实验项目切换器”，重点是隔离性和安全性，避免一个模块把整个系统搞崩。

这三种场景对架构的要求完全不同。场景一可以很粗糙，甚至用 HTTP 直接拉一个 bin 文件就行；场景二需要完整的包管理和回滚；场景三则需要沙箱和资源配额。我的建议是，先从场景一做起，把核心机制跑通，再逐步加复杂度。一上来就设计一套完整的签名、依赖、回滚体系，大概率会在调试阶段就放弃。

2.2 为什么不是“OTA 升级”换个名字

有人会说，这不就是 OTA 吗，ESP32 官方就支持 OTA，搞那么复杂干嘛。这里必须把概念掰清楚。

OTA 升级的本质是替换整个固件。你有一个完整的应用程序镜像，通过 Wi-Fi 下载新的镜像，写入另一个分区，然后重启切换。它的粒度是“整个固件”，每次升级都是全量替换。而应用商店的粒度是“功能模块”，底座固件不动，只加载或卸载某个模块。

这个区别带来的影响是巨大的。OTA 升级一次，哪怕只改了一个显示函数，也要传输几百 KB 到几 MB 的完整镜像，写入 Flash 需要几秒到几十秒，期间设备可能不可用。而模块化加载，一个功能模块可能只有几十 KB，加载时间在毫秒级，而且可以同时存在多个模块，按需激活。

更重要的是，OTA 升级后如果新固件有问题，回滚需要另一个完整镜像。而模块化架构下，卸载一个有问题的模块，或者切换到旧版本模块，成本极低。这就是为什么我说应用商店不是 OTA 的替代品，而是 OTA 的补充。底座固件用 OTA 升级，功能模块用应用商店管理，两者配合才是完整方案。

2.3 资源账：ESP32 到底能挤出多少空间

空谈架构没意义，得算账。以常见的 ESP32-WROOM-32 为例，4MB Flash 是标配，内部 SRAM 约 520KB，其中可用堆内存通常在 300KB 左右。如果带 PSRAM，可以额外有 4MB 或 8MB。

一个典型的 ESP-IDF 项目，底座固件如果包含 Wi-Fi、蓝牙、文件系统、HTTP 服务器、显示驱动，编译出来大概在 1.2MB 到 1.8MB 之间。分区表通常这样规划：

这样算下来，storage 分区有 1MB 空间。一个功能模块如果控制在 50KB 到 150KB 之间，可以存放 6 到 20 个模块。对于大多数场景，这个数量足够了。关键是要把模块做小，而不是把底座做大。我见过有人把整个 LVGL 图形库塞进每个模块，结果一个模块就 800KB，那确实没得玩。

内存方面，模块加载后占用的 RAM 取决于它做了什么。一个纯逻辑模块可能只占几 KB，一个带缓冲区的显示模块可能占几十 KB。我的经验是，同时激活的模块不要超过 3 个，每个模块的 RAM 占用控制在 50KB 以内，这样系统还有足够的余量处理网络和中断。

3. 核心机制拆解：模块怎么存、怎么加载、怎么隔离

3.1 模块的存储格式：不是随便扔个 bin 就行

最朴素的想法是，每个模块编译成一个 bin 文件，放到文件系统里，需要的时候读出来执行。但 ESP32 不是这样玩的。ESP32 的代码执行有两种方式：一种是直接从 Flash 通过 cache 映射执行，这要求代码放在特定的 app 分区；另一种是把代码加载到 RAM 里执行，但 RAM 就那么大，不现实。

所以模块化加载在 ESP32 上通常走的是动态加载 ELF 可执行文件的路线。ESP-IDF 从某个版本开始提供了esp_elf组件，可以解析 ELF 格式的可执行文件，把代码段和数据段加载到内存，解析符号，然后调用入口函数。这跟 Linux 的.so动态库思路类似，但简化了很多。

一个模块的 ELF 文件包含：

• 代码段：编译后的机器码，加载时复制到可执行内存区域
• 数据段：已初始化的全局变量和静态变量
• BSS 段：未初始化的全局变量，加载时清零
• 符号表：模块导出的函数和需要底座提供的函数
• 重定位表：告诉加载器哪些地址需要修正

编译模块的时候，需要指定底座固件导出的符号，这样模块才能调用底座的 API，比如显示、网络、存储。这里的关键是底座要导出一组稳定的 API，模块只能通过这些 API 访问系统资源，不能直接操作硬件寄存器。这是隔离性的基础。

注意：esp_elf组件对 ELF 文件有格式要求，不是随便一个 GCC 编译出来的 ELF 都能用。需要指定-fPIC编译位置无关代码，并且链接脚本要配合。我第一次尝试的时候，直接拿普通固件的 ELF 去加载，结果重定位表解析失败，折腾了一整天才找到原因。

3.2 加载流程：从文件到可执行代码的完整链路

模块加载的完整流程，我把它拆成六步，每一步都有坑。

第一步：读取 ELF 文件头。从文件系统打开模块文件，读取 ELF header，校验魔数、架构、类型。ESP32 是 Xtensa 或 RISC-V 架构，必须匹配。这一步失败通常是因为文件损坏或者编译目标不对。

第二步：解析程序头表。找到所有PT_LOAD类型的段，这些是需要加载到内存的段。每个段有虚拟地址、物理地址、文件偏移、大小、对齐要求。这里要注意，ESP32 的可执行内存区域是有限的，通常是 IRAM 和 DRAM 的某些区域。如果模块的代码段太大，加载会失败。

第三步：分配内存。根据程序头表，为每个段分配内存。代码段需要分配到可执行内存，数据段分配到可读写内存。ESP-IDF 提供了heap_caps_malloc可以指定内存能力，比如MALLOC_CAP_EXEC表示可执行。

第四步：复制段内容。把文件中的段内容复制到分配的内存中。BSS 段不需要复制，直接清零。

第五步：符号解析和重定位。这是最复杂的一步。模块中引用的外部符号，比如printf、esp_wifi_send，需要解析到底座固件中的实际地址。ELF 文件中的重定位表记录了哪些位置需要修正。加载器遍历重定位表，找到符号，计算实际地址，写入对应位置。

第六步：调用入口函数。模块通常有一个约定的入口函数，比如module_init。加载器找到这个符号的地址，调用它，模块开始运行。

整个过程听起来很线性，但实际调试的时候，最容易出问题的是第五步。符号找不到、重定位类型不支持、地址计算错误，都会导致加载失败或者运行时崩溃。我的建议是，先用一个最简单的模块测试，只导出一个函数，不调用任何底座 API，确认加载流程通了，再逐步加复杂度。

3.3 隔离性：模块崩了不能把系统带崩

模块化加载最大的风险是，一个模块里的野指针或者死循环，可能把整个系统搞挂。ESP32 没有 MMU（内存管理单元），只有 MPU（内存保护单元），保护能力有限。所以隔离性不能完全依赖硬件，得在软件层面做文章。

第一层隔离是 API 边界。模块只能调用底座导出的 API，不能直接访问硬件。底座在 API 内部做参数校验和资源检查。比如模块请求分配内存，底座可以限制单个模块的最大内存配额。

第二层隔离是任务隔离。每个模块运行在独立的任务里，有独立的栈空间。如果一个模块死循环，至少不会阻塞其他任务。底座可以监控模块任务的运行时间，超时后强制删除任务。

第三层隔离是看门狗。ESP32 有任务看门狗和中断看门狗。模块任务必须定期喂狗，否则看门狗触发，系统重启。这虽然粗暴，但至少能保证系统不会永久卡死。

第四层隔离是资源配额。底座记录每个模块打开的文件、socket、定时器数量，超过配额就拒绝新的请求。模块卸载时，底座负责回收所有资源，避免泄漏。

实操心得：我一开始没做资源配额，结果一个模块里有个 bug，不断创建定时器，最后把定时器池耗尽了，其他模块全部失效。后来加了配额，每个模块最多 4 个定时器，问题就解决了。这个教训告诉我，在资源受限的系统里，任何“无限”的假设都是危险的。

4. 动手实现：一个最小可用的模块加载器

4.1 底座固件的分区规划和编译配置

先规划分区。在partitions.csv里这样写：

# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 0x180000, storage, data, spiffs, 0x190000,0x100000,

factory 分区 1.5MB 给底座固件，storage 分区 1MB 给 SPIFFS 文件系统存放模块。注意 storage 的偏移要跟 factory 对齐，避免重叠。

然后配置底座固件，在menuconfig里打开几个关键选项：

• Component config -> ESP-ELF启用 ELF 加载器
• Component config -> Heap memory debugging打开堆调试，方便排查内存问题
• Component config -> FreeRTOS -> Enable task watchdog打开任务看门狗

底座固件需要导出一组 API 给模块用。在链接脚本里，用PROVIDE或者导出符号表的方式，把 API 函数暴露出来。我通常会在底座里定义一个api_table结构体，里面放函数指针，模块通过一个固定的符号名找到这个表。

// 底座导出的 API 表 typedef struct { void* (*malloc)(size_t size); void (*free)(void* ptr); int (*display_print)(const char* text); int (*wifi_send)(const uint8_t* data, size_t len); // ... 其他 API } module_api_t; module_api_t g_module_api = { .malloc = malloc, .free = free, .display_print = display_print, .wifi_send = wifi_send, };

模块编译时，声明一个外部符号extern module_api_t g_module_api;，然后通过它调用底座功能。这样底座升级 API 时，只要保持结构体布局兼容，模块不需要重新编译。

4.2 模块的编译：跟普通固件完全不同的流程

模块不能像普通固件那样编译。普通固件有完整的启动代码、中断向量表、链接脚本，而模块只是一个“半成品”，需要底座来补全。

模块的编译流程大致是这样：

1. 用-fPIC编译每个源文件，生成位置无关的目标文件
2. 用-shared链接，生成 ELF 共享对象
3. 链接时指定底座导出的符号表，确保模块引用的外部符号能解析
4. 用objcopy或者自定义工具，把 ELF 文件裁剪成适合加载的格式

我写了一个简单的 Makefile 模板：

MODULE_NAME := my_module SRCS := main.c utils.c CFLAGS := -fPIC -O2 -mlongcalls -I$(IDF_PATH)/components/esp_elf/include LDFLAGS := -shared -nostdlib -Wl,--gc-sections $(MODULE_NAME).elf: $(SRCS) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ module.bin: $(MODULE_NAME).elf esptool.py --chip esp32 elf2image --output $@ $<

注意-nostdlib表示不链接标准库，因为标准库函数由底座提供。-mlongcalls是 Xtensa 架构需要的，确保函数调用使用长调用指令，避免地址范围限制。

踩过的坑：模块里如果用到了浮点运算，需要确保底座启用了浮点支持，并且模块编译时链接了正确的浮点库。我有一次模块里用了sin函数，结果加载后调用时崩溃，查了半天发现是浮点寄存器保存问题。后来在底座的任务创建时加了configUSE_TASK_FPU_SUPPORT，问题解决。

4.3 加载器的核心代码：从文件到函数调用

加载器的核心逻辑，我简化成一个函数module_load，输入是文件路径，输出是模块句柄。

typedef struct { void* code_mem; void* data_mem; size_t code_size; size_t data_size; void (*entry)(module_api_t* api); char name[32]; } module_handle_t; module_handle_t* module_load(const char* path) { // 1. 打开文件 FILE* f = fopen(path, "rb"); if (!f) return NULL; // 2. 读取 ELF 头 Elf32_Ehdr ehdr; fread(&ehdr, sizeof(ehdr), 1, f); if (memcmp(ehdr.e_ident, ELFMAG, 4) != 0) { fclose(f); return NULL; } // 3. 解析程序头，找到需要加载的段 Elf32_Phdr phdr; size_t total_code = 0, total_data = 0; for (int i = 0; i < ehdr.e_phnum; i++) { fseek(f, ehdr.e_phoff + i * sizeof(phdr), SEEK_SET); fread(&phdr, sizeof(phdr), 1, f); if (phdr.p_type == PT_LOAD) { if (phdr.p_flags & PF_X) total_code += phdr.p_memsz; else total_data += phdr.p_memsz; } } // 4. 分配内存 module_handle_t* h = malloc(sizeof(module_handle_t)); h->code_mem = heap_caps_malloc(total_code, MALLOC_CAP_EXEC | MALLOC_CAP_32BIT); h->data_mem = heap_caps_malloc(total_data, MALLOC_CAP_8BIT); // 5. 复制段内容并重定位 // ... 省略详细代码，核心是遍历重定位表，修正地址 // 6. 找到入口函数 h->entry = (void (*)(module_api_t*))elf_find_symbol(&ehdr, f, "module_init"); fclose(f); return h; }

实际代码比这长得多，重定位部分尤其复杂。但核心思路就是这样：读文件、解析、分配内存、复制、重定位、找入口。

加载完成后，调用h->entry(&g_module_api)，模块就开始运行了。模块的module_init函数里，通常会创建一个任务，然后返回。底座记录这个模块的任务句柄，卸载时删除任务、释放内存。

4.4 模块的卸载：比加载更容易出问题

卸载模块听起来简单，释放内存就行。但实际上，卸载比加载更容易出问题，因为涉及到资源回收和任务清理。

第一步是通知模块准备卸载。底座调用模块导出的module_deinit函数，模块在这里关闭文件、释放自己分配的内存、停止定时器。如果模块不配合，底座只能强制清理。

第二步是删除模块任务。用vTaskDelete删除任务。但要注意，如果任务正在持有互斥锁或者正在访问共享资源，直接删除可能导致死锁。我的做法是，先设置一个标志位，模块任务检测到标志位后主动退出，等待一段时间后再强制删除。

第三步是释放内存。释放代码段和数据段内存。这里要注意，如果模块注册了回调函数到系统里，必须先注销，否则系统后续调用回调时会访问已释放的内存。

第四步是清理资源记录。底座维护一个资源表，记录模块打开的文件、socket、定时器。卸载时遍历这个表，强制关闭所有资源。

常见问题：模块卸载后，系统偶尔会崩溃。排查发现是模块里创建的任务没有完全退出，还在访问已释放的内存。后来我在卸载流程里加了vTaskDelay等待任务退出，并且用uxTaskGetSystemState检查任务是否真的删除了，问题才解决。卸载流程的健壮性，比加载流程更重要，因为加载失败最多是模块不能用，卸载失败可能导致整个系统崩溃。

5. 实际跑起来：一个完整的功能模块示例

5.1 模块功能定义：天气显示小部件

为了把上面的机制串起来，我做一个具体的模块：天气显示小部件。功能很简单，从网络获取天气数据，显示在屏幕上。它需要调用底座的 Wi-Fi API、HTTP API、显示 API。

模块的目录结构：

weather_module/ ├── Makefile ├── module.c ├── weather.c └── module.json

module.json描述模块的元信息：

{ "name": "weather", "version": "1.0.0", "author": "someone", "description": "显示实时天气", "entry": "module_init", "dependencies": ["wifi", "display"], "min_api_version": 1 }

底座读取这个文件，检查依赖是否满足，API 版本是否兼容，然后才加载模块。

5.2 模块代码：通过 API 表访问底座功能

模块的module.c里，核心是入口函数：

#include "module_api.h" extern module_api_t g_module_api; static TaskHandle_t weather_task = NULL; static bool running = false; static void weather_task_func(void* arg) { while (running) { // 获取天气数据 char buf[256]; int len = g_module_api.http_get("http://api.example.com/weather", buf, sizeof(buf)); if (len > 0) { // 解析并显示 g_module_api.display_clear(); g_module_api.display_print(buf); } vTaskDelay(pdMS_TO_TICKS(60000)); // 每分钟更新 } vTaskDelete(NULL); } int module_init(module_api_t* api) { running = true; xTaskCreate(weather_task_func, "weather", 4096, NULL, 5, &weather_task); return 0; } int module_deinit(void) { running = false; // 等待任务退出 vTaskDelay(pdMS_TO_TICKS(100)); return 0; }

注意模块里没有直接调用xTaskCreate，而是通过g_module_api间接调用。实际上xTaskCreate是 FreeRTOS 的函数，底座已经链接了 FreeRTOS，模块可以直接用。但为了隔离性，我倾向于把任务创建也封装到底座 API 里，这样底座可以控制模块的任务优先级和栈大小。

5.3 底座侧的模块管理：扫描、加载、卸载

底座启动后，扫描 storage 分区里的模块目录，读取每个模块的module.json，建立模块列表。然后提供一个简单的 HTTP 接口，让用户可以通过网页加载或卸载模块。

// 扫描模块目录 void scan_modules(void) { DIR* dir = opendir("/spiffs/modules"); struct dirent* entry; while ((entry = readdir(dir)) != NULL) { if (entry->d_type == DT_DIR) { char path[128]; snprintf(path, sizeof(path), "/spiffs/modules/%s/module.json", entry->d_name); module_info_t* info = parse_module_json(path); if (info) { add_to_module_list(info); } } } closedir(dir); } // HTTP 处理：加载模块 esp_err_t load_handler(httpd_req_t* req) { char name[32]; httpd_req_get_url_query_str(req, name, sizeof(name)); module_handle_t* h = module_load_by_name(name); if (h) { httpd_resp_sendstr(req, "OK"); } else { httpd_resp_send_err(req, HTTPD_500_INTERNAL_SERVER_ERROR, "Load failed"); } return ESP_OK; }

用户打开网页，看到模块列表，点击“加载”，底座调用module_load，模块开始运行。点击“卸载”，底座调用module_deinit，然后释放资源。

5.4 实测效果和性能数据

我在一块 ESP32-WROVER（带 4MB PSRAM）上实测，底座固件大小 1.4MB，storage 分区剩余约 900KB。天气模块编译出来 68KB，加载时间约 120ms，RAM 占用约 35KB（包括任务栈和缓冲区）。

同时加载三个模块（天气、时钟、系统信息），总 RAM 占用约 110KB，系统剩余堆内存约 180KB，运行稳定。加载第四个模块时，内存分配失败，说明三个模块是这块板子的实际上限。

加载时间方面，从 SPIFFS 读取 68KB 文件约 40ms，ELF 解析和重定位约 60ms，任务创建约 20ms。整体在 120ms 左右，用户几乎无感。如果模块更大，比如 200KB，加载时间会到 300ms 以上，这时候就需要考虑在加载时显示进度条，避免用户以为死机了。

6. 常见问题与排查技巧实录

6.1 加载失败：从错误码定位问题

模块加载失败是最常见的问题，错误可能出现在任何一个环节。我整理了一个排查表：

实操心得：我习惯在加载器的每个关键步骤加日志，用ESP_LOGI打印进度。这样加载失败时，看日志就知道卡在哪一步。日志级别在开发阶段设为 DEBUG，发布时改为 WARN，避免日志刷屏。

6.2 运行时崩溃：内存和栈的锅

模块加载成功但运行时崩溃，通常跟内存和栈有关。

栈溢出是最常见的。模块任务如果递归调用太深，或者局部变量太大，会撑爆任务栈。ESP-IDF 提供了栈溢出检测选项，在menuconfig里打开FreeRTOS -> Check for stack overflow，崩溃时会打印任务名和栈使用情况。

内存泄漏是第二常见的。模块里malloc了内存但忘记free，运行时间长了内存耗尽。底座可以在模块卸载时检查内存分配记录，如果模块还有未释放的内存，打印警告。

野指针是第三常见的。模块访问了已释放的内存，或者越界访问数组。ESP32 没有 MMU，野指针可能不会立即崩溃，而是悄悄破坏其他数据，导致难以定位的问题。我的做法是，在开发阶段启用堆内存填充和校验，menuconfig里打开Heap memory debugging -> Enable heap poisoning，这样释放的内存会被填充特定模式，访问时容易触发断言。

6.3 模块间冲突：资源竞争和符号冲突

多个模块同时运行时，可能出现资源竞争。比如两个模块都想用同一个定时器，或者都想占用显示缓冲区。

资源竞争的解决方法是底座统一管理资源。显示缓冲区由底座分配，模块通过 API 申请使用，底座用互斥锁保护。定时器也由底座统一分配，模块请求定时器时，底座返回一个句柄，模块通过句柄操作。

符号冲突是另一个问题。如果两个模块都定义了同名全局变量，加载时可能冲突。ELF 加载器通常按模块隔离符号，但底座导出的符号是全局的。我的做法是，模块内的全局变量都加static修饰，避免导出。模块间通信通过底座的消息队列，不直接共享内存。

6.4 版本兼容：API 变了怎么办

底座固件升级后，API 可能变化，旧模块可能不兼容。解决方法是 API 版本化。

底座导出的 API 表里，第一个字段是版本号。模块加载时，检查版本号是否在支持范围内。如果底座 API 升级，增加新函数，版本号加一，旧模块仍然可以用旧函数。如果删除了某个函数，版本号加一，旧模块加载时检查失败，提示用户更新模块。

typedef struct { uint32_t version; void* (*malloc)(size_t size); // ... 其他 API } module_api_t;

模块的module.json里声明min_api_version，底座加载时对比。这个机制看起来简单，但非常有效。我在实际项目中，底座 API 从 v1 升到 v3，旧模块仍然能正常运行，就是因为保持了向后兼容。

7. 这套东西到底值不值得做

回到最初的问题：在 ESP32 上做应用商店，到底有什么意义。

如果你的需求只是“让设备能远程升级”，那 OTA 就够了，没必要搞模块化加载。但如果你的需求是“让同一块硬件能快速切换功能，而且切换成本要低到用户无感”，那模块化加载确实有价值。

我自己的体会是，这套机制最大的价值不在于“商店”这个概念，而在于它强迫你把固件架构想清楚。底座负责什么，模块负责什么，API 边界在哪里，资源怎么管理，这些问题在传统固件开发里经常被忽略，因为“反正一起编译，能跑就行”。但一旦要做模块化，这些问题全部暴露出来，你必须认真设计。

另一个价值是开发效率。底座稳定后，开发新功能只需要写模块，编译快、烧录快、调试快。我做一个新模块，从写代码到加载运行，通常不超过十分钟。如果每次都要重新编译整个固件，这个时间至少翻倍。

当然，这套机制也有代价。ELF 加载器增加了固件复杂度，重定位和符号解析有性能开销，模块间隔离不是绝对的，一个恶意模块仍然可能搞崩系统。所以我的建议是，如果你的项目不需要动态加载功能，就不要引入这套机制。但如果你确实需要，那就从最简单的场景开始，逐步迭代，不要一上来就追求完美。