淺淺問一下，嵌入式那邊是不是都在用 protobuf ??？聽人說性能好、省流量、序列化快，移植過去代碼量好像也不大，乍一聽真是嵌入式傳輸協(xié)議的“理想型”。但真一上手搞起來，可能就發(fā)現(xiàn)事情沒那么簡單——嵌入式那點內(nèi)存，動不動就幾 KB 幾十 KB 的 RAM，你 protobuf 解出來那一堆動態(tài)分配、嵌套消息，稍不留神棧就溢出了，堆也 fragmentation 了，跑起來是快，可崩潰起來也真叫一個痛快。

再說了，調(diào)試的時候你怎么辦？抓個包看到的全是二進制流，你得一邊翻 .proto 文件一邊心里默默解碼，或者額外寫個小工具轉(zhuǎn)成能看的。萬一現(xiàn)場設(shè)備出點怪問題，你連數(shù)據(jù)長什么樣都一眼看不出來，是不是得先謝 protobuf 不殺之恩？這種時候你就會懷念 JSON 那種鍵值對明明白白、直接丟串口日志里都能肉眼比對的日子。所以說啊，嵌入式里選數(shù)據(jù)格式，真不能只看性能數(shù)字漂亮。

那怎么辦？跟上面那位老哥說的一樣，別做選擇，咱可以兩套都要。平時開發(fā)調(diào)試，先用 cJSON 或者 MessagePack 這類容易看懂的格式把業(yè)務(wù)邏輯打通，日志清晰，調(diào)起來不費眼。等到真要量產(chǎn)了、帶寬緊了、內(nèi)存算得準準的了，再換成 protobuf 也不遲。甚至你可以倆協(xié)議共存，調(diào)試模式走文本協(xié)議，發(fā)布模式切二進制——雖然得多寫點兼容代碼，但這可是給自己留了一條肉眼可看的后路啊。

畢竟嵌入式這玩意，一旦燒進去，追蹤難度比服務(wù)器大得多。你省那點帶寬和 CPU，可能最后全花在猜數(shù)據(jù)為什么不對上面了。性能要爭，可維護性也得留一手，這才是嵌入式老鳥的生存智慧。