一、嵌入式跨语言 IDL 怎么选？4 大维度 + 方案对比
很多人选型时盲目跟风微服务技术栈，直接把完整版 Protobuf+gRPC 往 MCU 里塞，结果固件爆 RAM、编译超 Flash，最后只能推倒重来。嵌入式 IDL 选型的第一原则是：资源优先，生态为辅，性能匹配场景。
1.1 嵌入式场景的核心约束
和服务器端不同，嵌入式跨语言数据交换有 4 个刚性约束，直接决定了选型边界：
1.2 主流方案横向对比
针对嵌入式 C++ 与 Python 数据交换场景，我们把 5 种常见方案的核心指标做了横向对比：
| FlatBuffers | 极低（零拷贝、零堆分配，纯头文件） | 极致（无解析开销，直接访问字段） | 中等 | 良好 | 全系列 MCU、大数据量传感器、实时控制 |
| Protobuf C++ Lite | 较低（轻量运行时，少量堆分配） | 高 | 极低 | 极高 | 中高端 MCU（Cortex-M4/H7 及以上） |
| Nanopb（Protobuf 纯 C） | 极低（全静态内存分配） | 高 | 中等 | 良好 | 低端 MCU（Cortex-M0/M3/M1） |
| Cap\’n Proto | 中等（零拷贝，自带 RPC） | 极致 | 偏高 | 一般 | Linux 级高端嵌入式、边缘节点 |
| JSON/CJSON | 高（解析耗内存 CPU） | 低 | 极低 | 极高 | 仅推荐调试用，不适合量产 |
1.3 分场景选型结论（直接对号入座）
绝大多数 MCU 场景首选：FlatBuffers 零拷贝、内存占用极致，不需要把整个报文解析成对象就能读取字段，C++ 端纯头文件实现，无需链接重型库，完美匹配嵌入式资源紧张、实时性要求高的特点。
团队已有 Protobuf 技术积累：选轻量化 Protobuf 中高端 MCU 用 Pr
