浅浅问一下，嵌入式那边是不是都在用 protobuf 啊？听人说性能好、省流量、序列化快，移植过去代码量好像也不大，乍一听真是嵌入式传输协议的“理想型”。但真一上手搞起来，可能就发现事情没那么简单——嵌入式那点内存，动不动就几 KB 几十 KB 的 RAM，你 protobuf 解出来那一堆动态分配、嵌套消息，稍不留神栈就溢出了，堆也 fragmentation 了，跑起来是快，可崩溃起来也真叫一个痛快。
再说了，调试的时候你怎么办？抓个包看到的全是二进制流，你得一边翻 .proto 文件一边心里默默解码，或者额外写个小工具转成能看的。万一现场设备出点怪问题，你连数据长什么样都一眼看不出来，是不是得先谢 protobuf 不杀之恩？这种时候你就会怀念 JSON 那种键值对明明白白、直接丢串口日志里都能肉眼比对的日子。所以说啊，嵌入式里选数据格式，真不能只看性能数字漂亮。
那怎么办？跟上面那位老哥说的一样，别做选择，咱可以两套都要。平时开发调试，先用 cJSON 或者 MessagePack 这类容易看懂的格式把业务逻辑打通，日志清晰，调起来不费眼。等到真要量产了、带宽紧了、内存算得准准的了，再换成 protobuf 也不迟。甚至你可以俩协议共存，调试模式走文本协议，发布模式切二进制——虽然得多写点兼容代码，但这可是给自己留了一条肉眼可看的后路啊。
毕竟嵌入式这玩意，一旦烧进去，追踪难度比服务器大得多。你省那点带宽和 CPU，可能最后全花在猜数据为什么不对上面了。性能要争，可维护性也得留一手，这才是嵌入式老鸟的生存智慧。
 never called错误)
