1. 為什么需要深入理解 Protobuf 編碼1.1 黑盒之外的現(xiàn)實(shí)場景做后端開發(fā)這些年跟 Protocol Buffers 打交道的時(shí)間不算短。RPC 通信、配置下發(fā)、數(shù)據(jù)落盤幾乎處處都有 proto 文件編譯出來的代碼在工作。但說實(shí)話很長一段時(shí)間里我對它的認(rèn)知停留在定義好 .proto 文件編譯成代碼調(diào)用序列化接口這個(gè)層面本體到底是怎么把結(jié)構(gòu)化數(shù)據(jù)變成一坨字節(jié)的從來沒仔細(xì)看過。直到有一次排查跨語言兼容性問題對著十六進(jìn)制報(bào)文發(fā)呆才痛下決心把 Protocol Buffers 的編碼原理整個(gè)啃了一遍。那之后我才意識到這個(gè)知識點(diǎn)不是學(xué)院派才需要的東西。線上出了問題最常見的三種場景全部依賴對編碼格式的理解第一兩個(gè)服務(wù)用的 proto 版本不一致老服務(wù)解析新字段時(shí)報(bào)錯或者靜默丟數(shù)據(jù)你要能從抓包數(shù)據(jù)里看出端倪第二性能優(yōu)化時(shí)糾結(jié)某個(gè)字段該用 int32 還是 sint32、該放 1 號字段還是 17 號字段不懂編碼結(jié)構(gòu)就只能靠猜第三日志或者 trace 里打出來一串十六進(jìn)制別人對著 Wireshark 能一眼定位問題你只能干瞪眼。這三種場景我全都經(jīng)歷過而且都是在毫無準(zhǔn)備的情況下被問題推到面前。1.2 適合誰以及能解決什么問題這篇文章不是給純小白科普Protobuf 是什么的至少你要能寫出一個(gè)簡單的 .proto 文件編譯過跑通過一次序列化反序列化。在此基礎(chǔ)上我會帶你從字節(jié)層面徹底拆解一條消息Varint 怎么編碼、tag 怎么組成、字符串和多層嵌套消息怎么帶長度前綴、packed repeated 字段到底省在哪里。學(xué)完之后你至少能做到三件事拿到一段十六進(jìn)制數(shù)據(jù)能徒手還原出原始消息的大致結(jié)構(gòu)在字段選的類型不合適導(dǎo)致包體膨脹時(shí)能準(zhǔn)確說出膨脹發(fā)生在哪幾個(gè)字節(jié)排查跨語言、跨版本的解析異常時(shí)不再是靠重啟和加日志碰運(yùn)氣。需要說明的是文章里所有手寫編碼的過程都是基于 Protocol Buffers 官方二進(jìn)制格式的常見實(shí)踐不同語言庫在邊界行為上略有差異但核心的線上格式是一致的只要理解了這個(gè)層面的規(guī)則任何語言的庫對你來說都不再是黑盒。2. VarintProtobuf 最底層的整數(shù)編碼2.1 七個(gè)比特一組的 base-128 方案Protocol Buffers 里面最常用、也最核心的整型編碼方式叫 Varint可變長整數(shù)。它的核心思路和 UTF-8 的變長機(jī)制有點(diǎn)像一個(gè)整數(shù)不一定非得用固定 4 字節(jié)或 8 字節(jié)來存而是根據(jù)數(shù)值大小動態(tài)決定占用幾個(gè)字節(jié)數(shù)值小就省空間數(shù)值大才擴(kuò)展。具體規(guī)則是把整數(shù)按 7 個(gè)比特一組從低位向高位切分每一組成為一個(gè)塊byte chunk然后在每個(gè)塊的最高位第 8 個(gè)比特即 MSB打上繼續(xù)或結(jié)束的標(biāo)記。如果這個(gè)塊后面還有后續(xù)塊MSB 置 1如果這是最后一個(gè)塊MSB 置 0。這樣解碼器讀到一個(gè)字節(jié)時(shí)先看最高位是 1 就接著讀是 0 就說明這個(gè) Varint 結(jié)束了。本質(zhì)上這就是一個(gè) base-128 的數(shù)字表示法只不過每個(gè)數(shù)字位占 1 個(gè)字節(jié)而不是 1 個(gè)字符而且用 MSB 作為連續(xù)的標(biāo)志位。它的好處是顯而易見的0 到 127 的整數(shù)只占 1 個(gè)字節(jié)128 到 16383 占 2 個(gè)字節(jié)絕大多數(shù)業(yè)務(wù)里的 ID、狀態(tài)碼、計(jì)數(shù)都落在很小的范圍內(nèi)所以整個(gè)消息體可以被壓得非常小。2.2 親手算一遍300 怎么變成 AC 02只看規(guī)則容易飄直接算一遍最踏實(shí)。Google 官方文檔里最經(jīng)典的例子就是整數(shù) 300 被編碼成兩個(gè)字節(jié)AC 02這個(gè)例子我建議每個(gè)人都親手推一遍推完 Varint 基本就懂了一半。先把 300 轉(zhuǎn)成二進(jìn)制300 256 32 8 4 0b100101100也就是 9 個(gè)比特1 0010 1100。按 7 比特一組從低位切分低 7 位是010 1100即十進(jìn)制的 44高位的剩余部分是10即十進(jìn)制的 2。所以 300 需要兩組塊來存。第一個(gè)塊存 44044 0x2C因?yàn)樗皇亲詈笠粋€(gè)塊MSB 置 1得到0xAC。第二個(gè)塊存 2002 0x02它是最后一個(gè)塊MSB 置 0所以還是0x02。合起來就是AC 02。解碼時(shí)讀0xAC發(fā)現(xiàn) MSB 是 1取低 7 位0x2C 44繼續(xù)讀讀0x02發(fā)現(xiàn) MSB 是 0取低 7 位0x02 2Varint 結(jié)束。然后按權(quán)重拼回來44 2 * 128 44 256 300。注意這里是低塊在前、高塊在后也就是小端順序千萬別把權(quán)重算反。我在初學(xué)的時(shí)候犯過一個(gè)低級錯誤就是把AC 02算成了172 2 174然后怎么都對不上。后來才意識到這里的字節(jié)順序和十六進(jìn)制閱讀習(xí)慣正好相反第一個(gè)字節(jié)反而是低位部分。建議你用類似uint32_t value byte 0x7F;然后value | (byte 0x7F) 7這種方式寫一段小驗(yàn)證腳本把亂序問題徹底釘死。2.3 負(fù)數(shù)與 sint32ZigZag 的取舍Varint 有一個(gè)天然的坑負(fù)數(shù)。在計(jì)算機(jī)里負(fù)數(shù)是用補(bǔ)碼表示的-1在 32 位整數(shù)里是0xFFFFFFFF如果直接拿這個(gè)值做 Varint會被切分成整整 5 個(gè)字節(jié)int32 補(bǔ)碼 32 位全 1而且因?yàn)?Protobuf 對 int32/int64 采用符號擴(kuò)展再編碼一個(gè)-1甚至?xí)痪幋a成 10 個(gè)字節(jié)FF FF FF FF FF FF FF FF FF 01。對于以負(fù)數(shù)為主的業(yè)務(wù)場景這簡直是災(zāi)難級膨脹。解決辦法是換用 sint32/sint64 配合 ZigZag 編碼。ZigZag 的思路是把有符號整數(shù)映射成無符號整數(shù)讓絕對值小的負(fù)數(shù)映射成小的正數(shù)。規(guī)則非常直觀0 - 0-1 - 11 - 2-2 - 32 - 4以此類推。公式是zigzag32(n) (n 1) ^ (n 31)對 64 位則右移 63 位。舉個(gè)例子-1通過 ZigZag 映射后變成1編碼成一個(gè)字節(jié)011映射成2也是01之外的第二個(gè)選擇-2映射成3。對比一下默認(rèn)的 int32 編碼-1占 10 字節(jié)sint32 占 1 字節(jié)。這就是為什么我強(qiáng)烈建議凡是業(yè)務(wù)上可能出現(xiàn)負(fù)數(shù)的地方直接用 sint32/sint64不要因?yàn)槟J(rèn)類型看起來通用就用 int32。默認(rèn)的 int 類型是給非負(fù)整數(shù)準(zhǔn)備的最優(yōu)解一旦引入負(fù)號它反而是最差的選擇。3. 字段標(biāo)識與 Wire Type 的設(shè)計(jì)邏輯3.1 tag 的構(gòu)成字段號為什么從 1 開始理解了 Varint下一個(gè)關(guān)鍵是字段標(biāo)識 TLVType-Length-Value中的 T。Protobuf 的每個(gè)字段在線上格式里并不是靠字段名來標(biāo)識的而是靠一個(gè)叫作 tag 的 Varint它同時(shí)攜帶兩個(gè)信息字段號field number和線類型wire type。tag 的計(jì)算公式是tag (field_number 3) | wire_type。也就是說字段號向左移 3 位騰出低 3 位來放 wire type。這也是為什么 proto 文件中字段號必須從 1 開始的根本原因字段號是編碼的一部分直接影響 tag 占用的字節(jié)數(shù)。字段號 1 到 15 的 tag 只用 1 個(gè)字節(jié)16 到 2047 的 tag 用了 2 個(gè)字節(jié)因?yàn)?6 3已經(jīng)超過 7 位2048 以上則更長。這個(gè)設(shè)計(jì)帶來的直接經(jīng)驗(yàn)是高頻字段、必填字段、核心字段盡量占住 1 到 15 的字段號位置低頻的、擴(kuò)展預(yù)留的字段放到大號段。很多團(tuán)隊(duì)不重視字段號規(guī)劃隨手把新字段加到 16 以后結(jié)果每個(gè)消息多出 1 到 2 字節(jié)在日調(diào)用量過億的服務(wù)里這是實(shí)打?qū)嵉膸捓速M(fèi)。3.2 Wire Type 全表wire type 就是 tag 低 3 位的值它告訴解析器這個(gè)字段后面跟的數(shù)據(jù)到底是哪種形狀。官方定義了 6 種其中兩種已廢棄Wire Type含義典型字段類型0Varintint32/64、uint32/64、sint32/64、bool、enum164-bit定長fixed64、sfixed64、double2Length-delimited帶長度前綴string、bytes、嵌入消息、packed repeated3Start group已廢棄老版本 group4End group已廢棄老版本 group532-bit定長fixed32、sfixed32、float這個(gè)表是整個(gè) Protobuf 編碼地圖的索引。解析器拿到一個(gè) tag 后只關(guān)心低 3 位的 wire type決定后面怎么讀高位的字段號則用來匹配對應(yīng)的字段定義。值得注意的是正因?yàn)?wire type 是編碼固有的一部分即使接收方不認(rèn)識某個(gè)字段號也能根據(jù) wire type 正確跳過對應(yīng)的字節(jié)這就是前后兼容性的底層保障。3.3 一個(gè)字節(jié)的 tag 怎么讀舉幾個(gè)最常見的 tag 例子幫助建立直覺。字段號 1、wire type 0Varint(1 3) | 0 0x08這一個(gè)字節(jié)就完成了標(biāo)識。字段號 2、wire type 2Length-delimited(2 3) | 2 0x12。字段號 3、wire type 20x1A。字段號 5、wire type 164-bit(5 3) | 1 0x29。字段號 1、wire type 532-bit(1 3) | 5 0x0D。當(dāng)你看到一段十六進(jìn)制數(shù)據(jù)以08開頭時(shí)立刻就能反應(yīng)出第一個(gè)字段字段號 1Varint 類型。這種直覺在調(diào)試時(shí)極其有用。如果 tag 的數(shù)值超過 127它就變成了一個(gè)多字節(jié) Varint解碼方式和前面完全一樣只是字段號比較大而已。關(guān)于 tag 還有一個(gè)容易被忽略的安全細(xì)節(jié)因?yàn)樽侄翁柺且莆黄闯鰜淼慕馕銎髟谶€原字段號時(shí)必須處理字段號 0 的情況官方明確規(guī)定字段號 0 是非法保留值。同時(shí)如果 tag 的 Varint 長度異常大也要在解析層做限制防止惡意構(gòu)造的超長 Varint 耗盡 CPU。這些在自研解析器時(shí)尤其要注意直接用官方庫通常不需要操心但了解邊界能幫助你在報(bào)錯時(shí)更快定位。4. 手寫一段完整的編碼逐字節(jié)拆解4.1 定義消息并準(zhǔn)備數(shù)據(jù)前面都是局部零件現(xiàn)在把它們組裝起來完整地手工編碼一條消息。我定義這樣一個(gè)最簡單的模型message Test { int32 id 1; string name 2; repeated int32 nums 3 [packed true]; }要編碼的數(shù)據(jù)是id 300name protobufnums [1, 2, 3]。這三個(gè)字段覆蓋了三種最主要的 wire typeVarint、Length-delimited、packed 的 Length-delimited。編碼后的完整字節(jié)流是08 AC 02 12 08 70 72 6F 74 6F 62 75 66 1A 03 01 02 03一共 18 個(gè)字節(jié)。如果是 JSON這段數(shù)據(jù)大概長這樣{id:300,name:protobuf,nums:[1,2,3]}占用幾十個(gè)字節(jié)。對比一下就明白 Protobuf 省空間的底氣從哪來了。4.2 逐字節(jié)編碼全過程從第一個(gè)字節(jié)開始拆。08字段號 1wire type 0是 Varint 類型的字段對應(yīng) proto 里的id。因?yàn)?id 的值是 300按前面 Varint 的規(guī)則編碼成兩字節(jié)AC 02。所以前三字節(jié)08 AC 02完整表達(dá)了id 300。接下來12這是 tag。字段號 2wire type 2Length-delimited對應(yīng)name字段。緊跟著的08是長度前綴表示后面的數(shù)據(jù)有 8 個(gè)字節(jié)。然后 8 個(gè)字節(jié)分別是protobuf這個(gè)字符串的 ASCII 碼70 72 6F 74 6F 62 75 66。這里能看到 Length-delimited 的精髓先告訴解碼器后面多長再給數(shù)據(jù)本體這樣解碼器不需要像 Varint 那樣靠 MSB 判斷結(jié)束位置直接按長度切就行。再往后1A字段號 3wire type 2對應(yīng)nums。因?yàn)閚ums是repeated int32且標(biāo)記了packed true所以三個(gè)整數(shù)不再單獨(dú)每個(gè)都帶 tag而是打包成一個(gè)連續(xù)的數(shù)據(jù)塊。03是長度表示后面 3 個(gè)字節(jié)。01 02 03就是三個(gè)被編碼成 Varint 的整數(shù) 1、2、3。每個(gè)整數(shù)恰好占 1 字節(jié)所以長度是 3。4.3 長度為前綴的嵌套消息如果字段類型是自定義消息message編碼規(guī)則和 string 一樣都是 Length-delimited先寫 tag再寫整個(gè)子消息的字節(jié)長度最后寫子消息的完整編碼。這個(gè)過程是遞歸的子消息內(nèi)部依然按 TLV 結(jié)構(gòu)組織。舉個(gè)例子如果有一個(gè)User消息包含一個(gè)Address字段那么編碼時(shí)是先把Address內(nèi)部所有字段編碼成一段連續(xù)的字節(jié)然后計(jì)算這段字節(jié)的長度把長度寫在前頭最后把 tag 寫在最外層。這種設(shè)計(jì)讓嵌套消息在二進(jìn)制層面的讀法跟 string 完全一致好處是解析器只需要一套通用的長度前綴邏輯就能處理任意深度的嵌套壞處是如果要修改嵌套內(nèi)部某個(gè)字段必須重建整棵子樹。這對理解大消息的性能特性很重要局部修改不等于局部編碼Protobuf 序列化通常是對整個(gè)對象樹重新編碼的。嵌套消息還有兩個(gè)值得注意的實(shí)踐要點(diǎn)。第一子消息的長度前綴本身是一個(gè) Varint如果子消息很大超過 127 字節(jié)這個(gè)長度占兩個(gè)字節(jié)這是實(shí)時(shí)計(jì)算出來的很多日志打印時(shí)會把長度和 tag 混在一起看容易誤判。第二如果子消息為空編出來的就是 tag 加上長度 0 兩個(gè)字節(jié)XX 00如果你在抓包里看到大量這種空殼消息說明業(yè)務(wù)層有很多空對象傳遞這是可以優(yōu)化的點(diǎn)。5. 常用類型的編碼細(xì)節(jié)與性能取舍5.1 定長類型與浮點(diǎn)數(shù)Varint 擅長小整數(shù)但對種子類的 double、fixed64 來說變長編碼反而沒有意義因?yàn)樗鼈兊?8 個(gè)字節(jié)幾乎無法壓縮。所以 Protobuf 為它們專門設(shè)計(jì)了 wire type 164-bit和 wire type 532-bit編碼時(shí)直接寫入固定長度的字節(jié)。這里有個(gè)反直覺的坑double 類型無論是 1.0 還是 100000.0都固定占 8 字節(jié)且按小端字節(jié)序直接寫入 IEEE 754 的二進(jìn)制表示float 固定占 4 字節(jié)。你可能會想小數(shù) 0 是不是能省答案是省不了定長就是定長。所以如果你的數(shù)據(jù)是大量的小數(shù)但數(shù)值范圍有限可以考慮把 double 換成用整數(shù)表示比如毫秒時(shí)間戳用 int64這會帶來數(shù)量級的空間差異。fixed32/fixed64 則適配另一類場景某些字段的值在業(yè)務(wù)上分布均勻比如哈希值、隨機(jī)數(shù)、ID 的散列結(jié)果用 Varint 反而因?yàn)楦呶唤?jīng)常有值而占更多字節(jié)定長反而穩(wěn)定。Google 官方的字段類型選型建議里就說得很清楚大部分場景用 int32/int64負(fù)數(shù)用 sint32/sint64值分布均勻或需要定長計(jì)算時(shí)用 fixed32/fixed64。5.2 packed 與 repeated 字段在 proto2 里repeated 數(shù)字字段默認(rèn)是不打包的每個(gè)元素都有自己的 tagproto3 里默認(rèn)是 packed。這兩者的編碼差異非常明顯。以repeated int32 nums 3為例不打包的編碼是1A 01 ... 1A 01 ... 1A 01 ...每個(gè)元素都帶一遍 tag打包的編碼是1A 03 01 02 03只帶一個(gè) tag、一個(gè)總長度然后所有元素連續(xù)排列。打包能省多少空間假設(shè)有 100 個(gè)值都是 1 到 127 的小整數(shù)打包版大約 100 2 字節(jié)非打包版是 100 * 2 字節(jié)。差了一倍。所以在 proto2 里只要不是必須保持元素順序和邊界可隨意跳過的場景都建議加上[packed true]。在 proto3 里這是默認(rèn)行為但要注意舊版本 proto2 服務(wù)如果讀到 proto3 客戶端發(fā)的 packed 包兼容性可能會出問題需要通過[packed false]臨時(shí)規(guī)避這屬于兼容性治理的范疇。5.3 map、oneof、enum 在二進(jìn)制層的樣子map 在編碼層面并沒有特殊的 wire type它是語法糖每個(gè)mapK,V對應(yīng)一個(gè) repeated 的 2 字段消息條目字段號固定 1 是 key字段號 2 是 value。比如mapstring, int32 scores編碼時(shí)每個(gè)鍵值對就是一個(gè)嵌入消息key 對應(yīng)字段號 1、value 對應(yīng)字段號 2。這意味著 map 無法保證元素順序而且每次序列化的順序可能隨機(jī)這點(diǎn)和 JSON 對象類似。oneof 在二進(jìn)制層就是普通的字段編碼只是保證同一時(shí)刻只有一個(gè)字段會被寫入。enum 本質(zhì)上是 Varint 編碼的整數(shù)tag 的 wire type 是 0。這里有個(gè)容易踩的坑enum 是int32的別名如果你定義的枚舉值是負(fù)數(shù)它同樣會觸發(fā) 10 字節(jié)膨脹所以枚舉值盡量不要用負(fù)數(shù)。字符串和 bytes 類型都是 Length-delimited唯一的區(qū)別是 bytes 不要求 UTF-8 合法性string 在部分語言的解析器里會做 UTF-8 校驗(yàn)?？缯Z言傳輸時(shí)如果一端塞了非法 UTF-8 進(jìn) string另一端解析可能直接拋錯這個(gè)問題的定位往往非常隱蔽因?yàn)檫@個(gè)差異只在二進(jìn)制解析層存在。6. 實(shí)操中常見的坑與排查實(shí)錄6.1 三個(gè)真實(shí)踩過的坑第一個(gè)坑是 int32 負(fù)數(shù)的 10 字節(jié)膨脹。我有一次做統(tǒng)計(jì)上報(bào)字段用的是 int32 存增量增量經(jīng)常為負(fù)結(jié)果發(fā)現(xiàn)上報(bào)包體比預(yù)期大了好幾倍。抓包一看一個(gè) -1 刷了一整行FF當(dāng)時(shí)就意識到類型選錯了。改成 sint32 之后負(fù)增量的包體瞬間降下來整個(gè)上報(bào)鏈路的帶寬占用減少了大約 40%。這個(gè)經(jīng)歷讓我養(yǎng)成了一個(gè)習(xí)慣定義 proto 字段前先問一句這個(gè)字段會不會出現(xiàn)負(fù)值。第二個(gè)坑是 packed 與非 packed 混跑。線上有兩個(gè)服務(wù)一個(gè)用 proto2 定義沒有[packedtrue]另一個(gè)升級到 proto3 后重復(fù)字段默認(rèn) packed結(jié)果老服務(wù)解析新服務(wù)的數(shù)據(jù)時(shí)出現(xiàn)了字段讀取異常。排查到最后才發(fā)現(xiàn)是打包方式不一致導(dǎo)致的。后來我們在所有跨版本接口中明確標(biāo)注打包策略并且用protoc --decode對比驗(yàn)證兩端解碼結(jié)果一致后才放量。第三個(gè)坑是嵌套層級過深導(dǎo)致的內(nèi)存放大。某個(gè)網(wǎng)關(guān)服務(wù)把收到的請求整體塞進(jìn)一個(gè)外層 message請求里又有數(shù)組數(shù)組元素又嵌套 message最深處有七八層。當(dāng)時(shí)做壓測發(fā)現(xiàn)內(nèi)存占用遠(yuǎn)大于原始數(shù)據(jù)大小。一查才知道每一層嵌套消息在解析時(shí)都會帶上整棵子對象樹的元數(shù)據(jù)層級深了之后內(nèi)存放大系數(shù)可以達(dá)到 10 倍以上。這個(gè)問題后來通過精簡消息結(jié)構(gòu)、把深層嵌套改成平鋪結(jié)構(gòu)解決。6.2 用 protoc 和 hexdump 定位問題遇到二進(jìn)制數(shù)據(jù)看不懂時(shí)我的標(biāo)準(zhǔn)流程是先用hexdump -C拿到原始字節(jié)再用 protoc 自帶的解碼工具做對照。protoc --decodeTest test.proto msg.bin protoc --decode_raw msg.bin第一條命令會用你定義的 proto 文件來解析二進(jìn)制輸出帶字段名的可讀結(jié)構(gòu)適合確認(rèn)語義。第二條命令不依賴 proto 文件直接把字節(jié)流按 wire type 拆成 tag-length-value 的形式輸出適合在沒有定義文件時(shí)快速定性。我通常先跑--decode_raw看整體結(jié)構(gòu)再用--decode對具體字段語義。這個(gè)組合幾乎能解決所有線上數(shù)據(jù)到底長什么樣的疑問。還有個(gè)實(shí)用技巧用xxd或者 Wireshark 的 ProtoBuf 解析插件。Wireshark 對 gRPC 流量能自動識別 protobuf 載荷并展開成字段樹對排查跨服務(wù)調(diào)用問題極其方便。不過要注意Wireshark 需要 .proto 文件才能解析出字段名沒有定義文件時(shí)只能看到 wire type 和原始值。6.3 編碼層優(yōu)化的小經(jīng)驗(yàn)最后分享幾條從編碼原理推導(dǎo)出來的優(yōu)化經(jīng)驗(yàn)。字段號規(guī)劃要趁早。字段號 1 到 15 的 tag 是 1 字節(jié)16 到 2047 是 2 字節(jié)。一個(gè)消息如果有 10 個(gè)熱字段都在 16 以后每個(gè)消息就多出 10 字節(jié)的 tag 開銷。在字段號分配時(shí)把高頻字段鎖死在 15 以內(nèi)低頻擴(kuò)展字段放后面這是零成本優(yōu)化。凡是可能出現(xiàn)負(fù)數(shù)的整型字段直接用 sint32/sint64。默認(rèn)的 int32 遇到負(fù)數(shù)會膨脹成 10 字節(jié)這是編碼格式?jīng)Q定的不是庫的性能問題改了字段類型立刻見效。大量的小整數(shù)數(shù)組務(wù)必確認(rèn)是 packed 編碼。proto3 默認(rèn)已經(jīng)打包proto2 要手動加[packedtrue]。這個(gè)優(yōu)化對批量 ID 查詢、批量上報(bào)這類接口影響非常大。字符串長度前綴本身是 Varint如果你的業(yè)務(wù)里經(jīng)常出現(xiàn)超過 127 字節(jié)的字符串長度前綴會從 1 字節(jié)變成 2 字節(jié)。對大字符串字段來說這可以忽略但如果一個(gè)消息里有幾十個(gè)大字符串字段積少成多也值得關(guān)注。我個(gè)人在實(shí)際操作中還有一個(gè)體會不要只依賴官方庫的序列化結(jié)果做正確性驗(yàn)證偶爾手工用--decode_raw解一段線上數(shù)據(jù)會逼著自己把 tag 結(jié)構(gòu)、長度前綴、Varint 邊界都過一遍。這個(gè)過程本身比讀十篇文檔都管用遇到跨語言兼容問題時(shí)的排查速度會有質(zhì)的提升。