1. 从一个反直觉的硬件决策说起
第一次听到"在 ESP32 上做应用商店"这个想法，我的反应和大多数人一样：这不是吃饱了撑的吗？一颗几块钱的 MCU，Flash 撑死 16MB，RAM 几百 KB，跑个 WiFi 协议栈都紧巴巴的，还搞应用商店？手机上的应用商店背后是成千上万台服务器、内容审核团队、CDN 分发网络，你一个单片机凑什么热闹。
但真正在嵌入式圈子里泡久了，尤其是做过几款量产 IoT 产品之后，我慢慢意识到这个问题的答案没那么简单。它问的其实不是"ESP32 能不能承载一个应用商店"，而是"当硬件足够便宜、联网足够普遍之后，固件的分发方式是不是该变一变了"。
这个标题背后藏着一个非常现实的工程痛点：传统固件是"烧录一次、终身不变"的，但用户的需求是不断变化的。你卖出去一万台智能插座，三个月后想加一个"电价分时统计"功能，按老办法你得重新编译固件、发 OTA 包、让用户升级、祈祷升级别变砖。而"应用商店"这个思路说的是：把功能拆成一个个可独立安装卸载的小应用，用户想要什么就装什么，厂商不用为每个组合重新发版。
所以这篇东西不是教你真去复刻一个手机应用商店，而是拆解这个想法在 ESP32 这类资源受限设备上到底意味着什么、技术上怎么落地、哪些坑必须提前知道。适合做 IoT 产品固件架构的开发者、玩 ESP32 想搞点花样的爱好者，以及任何对"嵌入式设备如何做动态功能扩展"感兴趣的人。下面我会从动机、技术底座、核心机制、实操细节到踩坑经验，一层层讲透。
2. 为什么"固件即应用"的老路越来越走不通
2.1 传统 OTA 的三个死结
先说清楚为什么大家会动"应用商店"这个念头。传统 OTA 升级在量产设备上有三个绕不过去的死结。
第一个是包体积和升级成本。一个完整的固件动辄 1MB 到 4MB，哪怕你只改了一行显示逻辑，用户也得下载整个包。对于走蜂窝网络、按流量计费的设备，这是真金白银的成本。我见过一个项目，设备分布在信号很差的偏远地区，一次全量 OTA 的流量费用比设备本身还贵。
第二个是功能耦合导致的回归风险。所有功能编译在一个固件里，改 A 功能不小心碰坏了 B 功能，这种事故在嵌入式里太常见了。因为大家共享全局变量、共享内存池、共享中断向量，牵一发动全身。你想只更新一个小功能，却不得不承担整个固件重新验证的成本。
第三个是无法满足个性化需求。同样是智能灯，有人只要开关和调色，有人想要音乐律动、想要场景联动、想要接入各种第三方协议。你不可能为每种组合出一个固件版本，那是组合爆炸。结果就是要么功能做得很臃肿，要么一部分用户的需求永远满足不了。
2.2 "应用商店"思路的本质：把功能变成可插拔的模块
"应用商店"这个说法其实是个比喻，它的技术本质是动态加载 + 独立分发 + 按需组合。把原本编译在一起的功能，拆成一个个独立的二进制模块，设备上跑一个轻量的"宿主"负责管理这些模块的下载、加载、运行和卸载。
这个思路在桌面和服务器领域早就成熟了，Linux 的.so、Windows 的.dll、浏览器的插件体系都是这个逻辑。但搬到 ESP32 上，难度完全不是一个量级。桌面系统有 MMU（内存管理单元），能把每个模块隔离在独立的虚拟地址空间里，一个模块崩了不影响别人。ESP32 用的是 Xtensa 或 RISC-V 内核，大多数型号没有 MMU，只有 MPU（内存保护单元），内存是平坦的物理地址空间，模块之间没有天然的隔离墙。
这就引出了整个方案最核心的技术挑战：在没有内存隔离的裸机环境里，如何安全地加载和运行一段外来的、可能有问题甚至恶意的代码。这个问题不解决，"应用商店"就是空中楼阁。后面几节我会重点讲这个。
2.3 什么场景下这套东西才真正划算
不是所有项目都值得上这套架构。我总结下来，满足下面几条里的两三条，才值得考虑：
- 设备出货量大，且功能需求会持续演进，OTA 频率高
- 功能模块之间相对独立，比如"传感器采集"和"屏幕显示"可以分开
- 有第三方开发者或生态伙伴想给你的设备写功能
- 设备部署在升级成本高、网络差的环境，需要最小化传输量
- 产品线希望用同一套宿主固件覆盖多个 SKU，靠装不同应用区分
反过来，如果你的设备功能固定、出货量小、没有第三方生态诉求，那老老实实做全量 OTA 更省心。别为了架构而架构，这是我在好几个项目里交过学费才明白的道理。
3. ESP32 上跑动态应用，硬件到底给不给力
3.1 内存布局：IRAM、DRAM、Flash 的分工
要理解动态加载，先得搞清楚 ESP32 的内存地图。以经典的 ESP32（Xtensa 双核）为例，内存大致分几块：
| 区域 | 典型容量 | 用途 | 能否执行代码 |
|---|---|---|---|
| IRAM | 128KB 左右 | 中断处理、高频代码 | 是 |
| DRAM | 320KB 左右 | 数据、堆、栈 | 否 |
| Flash (mmap) | 4-16MB | 代码、常量、文件系统 | 是（通过 cache） |
| PSRAM | 可选 2-8MB | 大缓冲、堆扩展 | 否（部分型号可执行） |
关键点在于：ESP32 的代码可以从 Flash 直接执行，靠的是指令 cache 把 Flash 里的代码映射到 CPU 的取指路径上。这意味着你不需要把整个应用拷进 RAM 才能跑，只要把代码放在 Flash 的某个分区里，配置好 mmap，CPU 就能直接执行。这是动态加载能成立的前提。
但有个坑：从 Flash 执行的代码，如果被 cache 换出，性能会抖。所以中断服务程序、时序敏感的代码必须放在 IRAM 里。而 IRAM 只有 128KB，宿主自己就要占掉一大半，留给应用的空间非常有限。这就决定了：应用里不能有中断处理逻辑，所有中断必须由宿主统一接管再分发。
3.2 分区表：应用商店的"货架"
ESP32 的 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, app_slot_a, app, ota_0, 0x1A0000, 0x180000, app_slot_b, app, ota_1, 0x320000, 0x180000, apps_pool, data, fat, 0x4A0000, 0x300000, app_meta, data, nvs, 0x7A0000, 0x10000,这里apps_pool就是"货架"，用 FAT 或 LittleFS 文件系统格式化，每个应用是一个独立的二进制文件加一份元数据。app_meta存应用的索引、版本、依赖关系、校验值。宿主启动时扫描这个分区，把可用应用列出来，这就是"商店"的目录。
我实测下来，用 LittleFS 比 FAT 更省心，因为它对断电和坏块的容忍度更好，嵌入式设备随时可能掉电，文件系统损坏是家常便饭。代价是 LittleFS 的目录操作稍慢，但应用列表这种低频操作完全能接受。
3.3 算一笔账：一个应用能有多大
假设你用 4MB Flash 的模组，分区表如上，apps_pool给了 3MB。听起来不少，但要注意：
- 每个应用要预留对齐和元数据开销，实际可用约 2.8MB
- 如果同时装 10 个应用，平均每个 280KB
- 一个带简单 UI 和网络功能的应用，编译出来通常 150-400KB
所以结论是：能装，但装不了太多，且每个应用都得精打细算。这跟手机上动辄几百 MB 的应用完全不是一个概念。你得接受"应用就是个小功能模块"这个定位，别指望在 ESP32 上跑一个完整的浏览器。
如果换成 8MB 或 16MB Flash 的模组，空间会宽裕很多，但成本也上去了。这里有个经验：Flash 容量是这套架构最该舍得花钱的地方，因为它直接决定了你能装多少应用、能不能做 A/B 双备份。省这点 Flash 钱，后面架构上会处处受限。
4. 动态加载的核心：ELF 解析与符号重定位
4.1 为什么是 ELF，而不是自己造格式
应用二进制用什么格式？最省事的做法是直接用 ELF（可执行与可链接格式）。原因很简单：编译器天然产出 ELF，工具链现成，不用自己写打包器。你只需要在设备端写一个精简的 ELF 加载器，把.text、.rodata、.data这些段搬到正确的位置，处理符号重定位就行。
自己造格式的诱惑我也理解——觉得 ELF 太复杂，想搞个简单的。但我劝你别。自己造格式意味着你要自己写链接脚本、自己处理重定位、自己维护工具链，工作量比写个 ELF 加载器大得多，而且容易出隐蔽 bug。ESP-IDF 本身就带 ELF 解析的底层能力，站在巨人肩膀上不丢人。
4.2 重定位：让应用"找到"宿主的函数
动态加载最难理解的部分是符号重定位。应用在编译时，并不知道自己会被加载到 Flash 的哪个地址，也不知道宿主提供的函数（比如host_printf、host_gpio_set）在哪个地址。这些都得在加载时动态填上。
流程是这样的：
- 应用编译成位置无关代码（PIC），或者编译时假设一个基地址
- 应用里对宿主函数的调用，先留一个占位符，记录在重定位表里
- 宿主加载应用时，遍历重定位表，把每个占位符替换成宿主函数的真实地址
- 应用里对自身数据的访问，也要根据实际加载地址做偏移修正
ESP32 的 Xtensa 架构支持两种重定位方式：一种是绝对地址重定位，简单但要求应用加载到固定地址；另一种是相对地址重定位（类似 PC-relative），灵活但编译器支持要到位。我建议用固定基地址 + 绝对重定位，因为 ESP32 的 Flash mmap 地址是固定的，应用加载到哪个分区、映射到哪个地址，都是确定的，没必要搞复杂的 PIC。
具体操作上，你需要给应用单独写一个链接脚本，把代码段的起始地址设成它在 Flash 里的 mmap 地址。比如应用装在apps_pool的偏移 0x10000 处，而apps_pool映射到 CPU 地址空间的 0x3F400000，那应用的链接地址就是 0x3F410000。这样编译出来的 ELF，重定位信息就是对的，加载器只需要处理宿主符号的填充。
4.3 宿主 API：应用能调用的"系统调用"
应用不能直接碰硬件寄存器，也不能直接调用 ESP-IDF 的任意函数，否则隔离就无从谈起。宿主必须提供一套受控的 API 接口，应用只能通过这套接口跟外界交互。
这套 API 的设计有几个原则：
- 最小权限：应用要什么给什么，不要暴露底层句柄。比如给
host_gpio_write(pin, level)，而不是给寄存器地址。 - 参数校验：每个 API 入口都要校验参数合法性，防止应用传个越界指针把宿主搞崩。
- 资源配额：应用申请内存、打开 socket、创建定时器，都要有配额限制，防止一个应用吃光资源。
- 可审计：关键操作要能记录日志，出问题时能追溯是哪个应用干的。
一个典型的宿主 API 表长这样：
typedef struct { int (*printf)(const char *fmt, ...); void *(*malloc)(size_t size); void (*free)(void *ptr); int (*gpio_write)(int pin, int level); int (*gpio_read)(int pin); int (*timer_create)(uint32_t ms, void (*cb)(void *), void *arg); int (*timer_delete)(int handle); int (*http_get)(const char *url, char *buf, size_t len); // ... 更多接口 } host_api_t;应用启动时，宿主把这个结构体的指针传给应用的入口函数，应用就通过它来调用一切。这个结构体本身放在宿主的只读内存里，应用改不了，保证了接口的完整性。
5. 没有 MMU 怎么隔离：MPU 与软件沙箱的组合拳
5.1 MPU 能做什么，不能做什么
ESP32 的 MPU 可以配置若干内存区域，给每个区域设置读/写/执行权限。理论上你可以给每个应用划一块区域，设成"只能读自己的代码、只能读写自己的数据"，这样应用 A 就碰不到应用 B 和宿主的数据。
但 MPU 有几个硬限制，必须清楚：
- 区域数量有限：ESP32 的 MPU 通常只有 8 个左右的区域，宿主自己就要用掉几个，留给应用的没几个。
- 粒度粗：区域大小必须是 2 的幂，且对齐要求严格，容易造成内存浪费。
- 只管数据，不管控制流：MPU 能阻止应用写宿主的数据，但阻止不了应用跳转到宿主的代码里执行（如果那段代码可执行的话）。
- 配置复杂：MPU 配置错了，轻则应用跑不起来，重则整个系统异常。
所以我的结论是：MPU 是必要的，但远远不够。它能挡住一部分越界访问，但挡不住精心构造的恶意代码。真正的安全还得靠软件层面的沙箱。
5.2 软件沙箱：把危险操作全部收口
软件沙箱的核心思想是：应用能做的每一件"危险"的事，都必须经过宿主的检查。具体来说：
- 应用不能直接访问内存，所有内存访问要么在自己的数据段内（MPU 保证），要么通过宿主 API 间接进行
- 应用不能直接调用系统函数，只能调用宿主 API 表里的函数
- 应用不能创建中断，中断由宿主统一管理
- 应用不能长时间占用 CPU，宿主用看门狗和调度器强制抢占
- 应用不能无限申请资源，宿主对每类资源设配额
这套机制里，最容易被忽视的是 CPU 时间配额。我踩过一个坑：某个应用里写了个死循环，因为没开抢占式调度，直接把整个设备卡死了，看门狗都没来得及复位。后来改成宿主用定时器中断强制切换上下文，每个应用最多跑 10ms 就必须让出，问题才解决。
5.3 崩溃隔离：一个应用挂了不能拖垮全场
再好的沙箱也挡不住应用自己写 bug 崩溃。关键是崩溃要能被捕获，且不影响其他应用和宿主。
做法是给每个应用设置独立的栈和异常处理。当应用触发异常（比如除零、非法指令、访问越界），CPU 跳到宿主的异常处理程序，宿主识别出是哪个应用崩了，把它标记为"故障"，卸载掉，然后继续跑其他应用。宿主自己绝不能因为应用的异常而进入 panic。
这里有个细节：ESP32 的异常处理默认会打印一堆寄存器信息然后重启。你要做的是接管异常向量，在 panic 之前拦截，判断异常发生在哪个上下文。如果发生在应用上下文，就优雅地卸载应用；如果发生在宿主上下文，那才是真 bug，该重启重启。
实测下来，这套机制能把"一个应用崩溃导致整机重启"的概率降到很低。但要注意，如果应用崩溃时正持有某个宿主资源（比如一个锁），宿主必须有能力回收这个资源，否则会死锁。所以宿主 API 里凡是涉及资源的，都要记录"谁在用"，应用卸载时统一清理。
6. 从零搭一个最小可用的应用商店原型
6.1 宿主固件的骨架
宿主固件是整个系统的核心，它要干这几件事：初始化硬件、挂载文件系统、扫描应用列表、提供 API、调度应用、处理崩溃。骨架大概是这样：
void app_main(void) { // 1. 基础初始化 nvs_flash_init(); init_flash_mmap(); // 映射 apps_pool 到地址空间 mount_littlefs("/apps"); // 挂载应用分区 // 2. 初始化宿主服务 host_api_init(); // 准备 API 表 scheduler_init(); // 初始化应用调度器 crash_handler_install(); // 安装异常处理 // 3. 扫描并加载已安装应用 app_list_t *list = app_scan("/apps"); for (int i = 0; i < list->count; i++) { app_load(list->apps[i]); } // 4. 主循环：调度应用运行 while (1) { scheduler_tick(); vTaskDelay(pdMS_TO_TICKS(10)); } }这个骨架看起来简单，但每一行背后都有讲究。比如init_flash_mmap要把应用分区映射到 CPU 能执行的地址，这需要调用esp_partition_mmap，并且要确保映射的区域有执行权限。app_scan要读元数据、校验签名、检查依赖，任何一步失败都要能优雅跳过而不是崩溃。
6.2 应用的生命周期管理
一个应用从"被安装"到"被卸载"，中间经历好几个状态，宿主得管好每个状态的转换：
| 状态 | 含义 | 宿主动作 |
|---|---|---|
| INSTALLED | 已下载，未加载 | 校验签名和完整性 |
| LOADED | 已加载到内存，未运行 | 完成重定位，准备入口 |
| RUNNING | 正在运行 | 分配时间片，监控资源 |
| SUSPENDED | 被挂起 | 保存上下文，释放 CPU |
| FAULTED | 崩溃了 | 记录日志，准备卸载 |
| UNINSTALLED | 已卸载 | 释放所有资源，删除文件 |
状态转换里最容易出问题的是 SUSPENDED 和 RUNNING 之间的切换。应用被挂起时，它的栈、寄存器、堆状态都得保存好，恢复时要一模一样地还原。如果应用里有正在进行的网络请求或定时器，挂起时要么等它完成，要么取消掉，不能悬着。
我的经验是：尽量少用挂起，能用"让出"就用"让出"。让出是应用主动调用host_yield()放弃 CPU，上下文由应用自己维护，宿主不用管。挂起是宿主强制剥夺 CPU，上下文得宿主保存，复杂且容易出错。除非应用不配合（比如死循环），否则优先用协作式让出。
6.3 应用打包与签名
应用不是随便一个 ELF 就能装的，得打包成宿主认识的格式，并且签名防篡改。打包流程：
- 编译应用，产出 ELF
- 用工具提取需要的段（
.text、.rodata、.data），去掉调试信息 - 生成元数据：应用名、版本、作者、依赖的宿主 API 版本、入口符号名
- 把段和元数据打包成一个文件，头部加魔数和长度
- 对整个包做哈希，用私钥签名，签名附在包尾
宿主安装时，先用公钥验签，验签通过才解包加载。这样即使应用分发渠道被污染，攻击者没有私钥也伪造不了合法应用。签名算法用 Ed25519 比较合适，密钥短、验签快，ESP32 上跑起来没压力。
这里有个实操细节：验签要在加载之前做，且验签用的公钥要烧在宿主固件里，不能放在可写分区。我见过一个设计把公钥放在文件系统里，结果攻击者把公钥换掉，签名验证形同虚设。公钥必须编译进宿主代码，或者烧到 eFuse 里，让它改不了。
7. 那些文档不会告诉你的坑
7.1 Flash 擦写寿命与文件系统的博弈
应用商店意味着频繁的安装卸载，也就是频繁的 Flash 擦写。ESP32 外挂的 SPI Flash 擦写寿命通常标称 10 万次，听起来很多，但如果你把应用元数据、索引、日志都写在一个块里，很快就会写坏。
我的做法是：元数据和索引放在 NVS 里，NVS 自带磨损均衡；应用文件放在 LittleFS 里，LittleFS 也有磨损均衡。两者都不要自己直接操作 Flash 扇区。另外，应用列表这种读多写少的数据，可以在 RAM 里缓存一份，减少实际写次数。
还有一个坑：掉电时机。用户正在安装应用时突然断电，可能留下一个半截的文件。宿主启动扫描时必须能识别并清理这种"孤儿文件"，否则会反复尝试加载一个损坏的应用。LittleFS 本身对断电有一定容忍，但你的应用安装逻辑也要做原子性保证——先写临时文件，写完校验通过再改名，改名是原子操作。
7.2 堆碎片：动态加载的隐形杀手
应用反复加载卸载，堆会碎片化。ESP32 的堆本来就不大，碎片一多，明明总空闲内存够，却分配不出连续的大块，导致加载失败。
缓解办法有几个：
- 给每个应用预分配固定大小的内存池，应用的内存都从这个池里出，卸载时整池回收，不产生碎片
- 应用代码尽量从 Flash 执行，不占 RAM，只有数据段进 RAM
- 限制单个应用的最大内存占用，超了就拒绝加载
- 定期整理：在系统空闲时，把还活着的应用数据搬到一起，腾出连续空间
最后一条实现起来复杂，我一般不用。前三条配合好，基本能控制住碎片问题。实测一个跑了几个月的设备，反复装卸应用几百次，堆碎片率能控制在 10% 以内。
7.3 版本兼容：宿主升级了，老应用怎么办
这是最头疼的问题之一。宿主固件升级后，API 表可能变了——加了新函数、改了函数签名、删了废弃接口。老应用如果还按旧 API 调用，轻则功能异常，重则崩溃。
解决办法是API 版本化。宿主 API 表里带一个版本号，应用元数据里声明它需要的 API 版本范围。加载时宿主检查：如果应用要求的版本宿主不支持，就拒绝加载并提示用户升级应用。
更进一步，宿主可以同时维护多个版本的 API 表，老应用调老表，新应用调新表。但这会显著增加宿主体积和复杂度，一般只在 API 变动很大时才值得。我的建议是：API 只增不改不删，废弃的接口保留但标记 deprecated，这样老应用永远能跑，新应用用新接口。空间换兼容，在嵌入式里通常是划算的。
8. 这套架构真正跑起来之后的价值
8.1 对厂商：一次开发，多 SKU 覆盖
最直接的好处是产品线管理变简单了。同一套宿主固件，装不同的应用组合，就是不同的产品。基础款只装"开关控制"，高级款加装"场景联动""能耗统计""语音助手"。生产时不用烧不同固件，统一烧宿主，然后按订单装应用。库存管理、售后维护都省事。
我参与过一个项目，原本有 6 个 SKU，每个 SKU 一套固件，维护起来是噩梦。改成宿主 + 应用架构后，宿主一套，应用 6 个，代码复用率大幅提升，发版频率从每月一次降到每季度一次。
8.2 对开发者：降低门槛，激活生态
第三方开发者想给你的设备写功能，以前得拿到完整固件源码、搭好整套编译环境、理解所有硬件细节。现在只需要针对宿主 API 写应用，编译成标准格式，签名后上传。门槛低了一个数量级。
这带来的可能性是：设备的功能边界由社区决定，而不是由厂商的研发排期决定。有人想要个冷门功能，厂商没精力做，社区里有人做了，传上去，其他用户就能装。这种生态效应在开源硬件圈子里已经验证过很多次。
8.3 对用户：按需定制，不臃肿
用户拿到设备，只装自己需要的功能。不需要的功能不占空间、不耗电、不增加攻击面。想要新功能，商店里找一找，装上就行，不用等厂商发固件。这种体验在手机上是理所当然的，在 IoT 设备上还是新鲜事。
当然，前提是商店里的应用质量有保障。这就回到内容审核和签名机制——没有审核，商店会变成垃圾场；没有签名，商店会变成攻击入口。这两件事做不好，应用商店的价值就是负的。
9. 我踩过的几个真实坑与应对
第一个坑是符号冲突。两个应用都定义了一个叫init的全局函数，加载第二个时，重定位把第一个的调用也指到了第二个的init上，导致第一个应用行为异常。解决办法是给每个应用的符号加命名空间前缀，或者加载时做符号隔离，每个应用维护独立的符号表。我后来在打包工具里自动给所有全局符号加应用 ID 前缀，问题就没了。
第二个坑是看门狗误触发。应用在做一次耗时的 Flash 写入，超过了看门狗的喂狗周期，宿主没来得及喂狗，设备重启。解决办法是宿主在调用可能耗时的 API 时，临时调整看门狗超时，或者在这些 API 内部主动喂狗。但要注意，不能让应用自己控制看门狗，否则恶意应用可以永久占用 CPU。
第三个坑是应用间通信。一开始没设计应用间通信机制，两个应用想交换数据只能通过宿主中转，效率低。后来加了一套基于消息队列的 IPC，应用可以互相发消息，宿主负责路由和权限检查。但这也带来了新问题：应用 A 给应用 B 发消息，B 崩了，消息丢了怎么办？最后加了消息持久化和重传，复杂度上去了，但可靠性有了。
第四个坑是调试困难。应用跑在宿主里，出了问题是应用的 bug 还是宿主的 bug，很难判断。后来在宿主里加了一套详细的日志系统，每个 API 调用都记录调用者、参数、返回值，出问题时能完整还原调用链。这套日志在开发阶段帮了大忙，量产时可以关掉或降级。
10. 关于这件事到底值不值得做
回到标题那个问题：在 ESP32 上做应用商店，到底有什么意义？
我的答案是：它的意义不在于"商店"这个形式，而在于它倒逼你把固件架构从"铁板一块"改成"模块化、可组合、可演进"。哪怕你最后没做成真正的商店，只是把功能拆成了几个可独立更新的模块，这个架构升级本身就已经值回票价了。
但我也得泼盆冷水：这套东西的复杂度不低，从 ELF 加载、重定位、MPU 配置、沙箱设计到崩溃隔离，每一块都有坑。如果你的团队没有嵌入式底层经验，或者项目周期很紧，别硬上。先用全量 OTA 把产品跑起来，等有了稳定的用户群和明确的扩展需求，再考虑架构升级。
最后分享一个我自己的判断标准：当你发现"为了加一个小功能，不得不重新验证整个固件"这件事每周都在发生时，就是该考虑模块化的时候了。在那之前，把精力花在把产品做稳定、把用户需求摸清楚上，比折腾架构更实在。技术选型永远服务于业务节奏，别让架构的优雅绑架了产品的速度。
