安全的變更由編碼規則界定

protobuf 官方語言規範把 schema 變更分三類：wire-unsafe、wire-safe（加欄位、加 enum 值、刪欄位皆安全）、conditionally wire-compatible（見 11.C28）。判準是 wire format 認不認得出差異、不是欄位語意變沒變。加欄位安全、因為舊 client 不認得新編號就跳過；刪欄位安全、因為對應編號的資料被當未知欄位忽略。

這條規則的硬核是 field number 不可重用。編號一旦投入使用即固定、因為它就是 wire 上的欄位身分；刪欄位後必須 reserved 該編號、擋住未來誤用。重用一個舊編號、wire 解碼會把新欄位的 bytes 當成舊欄位解、後果落在資料層 — 官方列舉的後果包含 parse / merge error、PII 洩漏、資料損毀；解碼報錯只是其中一種結局、多數情況是靜默的損毀。使用層的操作紀律因此只有兩條：只加不改、刪了就永久 reserve 編號。把相容性做進編碼層不是 protobuf 獨有 —— Thrift 的 field id、Avro 的 schema resolution 是同一類機制、演進判準類似；本文聚焦 protobuf 是因為它的生態成熟度（buf）與本模組的案例密度。

從自律升級成 CI gate

編碼規則界定了安全範圍、但「只加不改」靠人腦守不住 — 破壞發生在多層、改欄位名破壞 generated code、改型別破壞 wire format、人工 review 抓不全。buf breaking 把這條紀律做成 merge 前的自動檢查：對比歷史版本 schema、擋下如「Field 1 type int32 改 string」這類變更。官方文件對這個定位的措辭直接 —「Catching this before merge is the point」（見 11.C29、Buf 官方文件）。

使用層要做的判斷不是「要不要開這個檢查」、而是「檢查到哪一級」。buf 的規則分四級、嚴格程度遞增：WIRE（只保 wire 相容）、WIRE_JSON、PACKAGE、FILE。等級的選擇是產品決策、對應消費者實際依賴的形狀：消費者只透過 wire 通訊、選 WIRE 就夠；有外部程式碼直接 import 你的 generated package、就要 PACKAGE 擋住改套件路徑這種對 wire 無害、卻會炸掉別人 build 的變更。等級選太寬會放行破壞、選太嚴會擋住原本安全的重構 — 判準永遠是回到「誰在依賴這個 schema、依賴到哪一層」。

契約放哪裡：與 tRPC 的對照

proto 演進紀律的本質是把契約外置成一份 IDL（介面定義語言）檔、相容性檢查對這份檔做。這跟 rpc-revival 的 tRPC 路線 形成選型上的對照：tRPC 把契約放進 TypeScript 型別系統、靠推導同步、不產 IDL 檔。兩者都在解「契約怎麼跨 client/server 同步」、差別在契約放在哪 —— proto 外置換到跨語言與 CI 可檢、代價是要維護 IDL 與 codegen；型別內嵌換到零 codegen 的開發體驗、代價是鎖定單一語言。演進成本這條選型軸就是在問團隊承擔得起哪種紀律、判準見 11.2。

下一步路由

• 跨風格的變更紀律框架：11.6 向後相容的變更紀律
• 選了 gRPC 之後的部署約束：streaming 與部署邊界
• gRPC 值得選的組織前提：內部 RPC 的選型位置
• 契約放型別系統的對照路線：tRPC 型別共享
• 案例原文：模組十一案例庫

trailers 與瀏覽器：協議事實層面的約束

gRPC 用 HTTP/2 的 trailers（在 response body 之後才送的 metadata）傳狀態碼、這是協議規格、不是實作選擇。約束由此而來：瀏覽器的 fetch API 讀不到 trailers、所以瀏覽器不能直接當 gRPC client、要靠 gRPC-Web 加一個翻譯 proxy 把 trailers 搬進 body（見 11.C32、獨立實踐者批評）。同樣的 trailers 依賴也讓中間層變挑剔 —— 不是每個 LB、proxy、防火牆規則都原樣放行 HTTP/2 trailers。

這條約束值得跟立場切開看。指出它最完整的一手清單來自 Buf 的 Connect 發布文（見 11.C30）、而 Buf 是提供競品的利益相關方、它對 grpc-go 實作的批評（自帶 HTTP/2、不與其他 HTTP 流量共存）帶立場。但「瀏覽器讀不到 trailers、需要翻譯 proxy」是可獨立驗證的協議事實、跟誰在批評無關 —— C32 的獨立批評指向同一點、兩個來源互證後這條約束脫離 vendor 立場成立。使用層的判讀：如果介面要被瀏覽器直接消費、gRPC-Web 加 proxy 是必經的一層、選型時就要把這層 infra 算進成本。

這組約束有一條中間路線。同一份 C30 除了批評、也給了解方 Connect protocol：建在 net/http 上、以 HTTP/1.1 承載、同時支援 gRPC、gRPC-Web、Connect 三種協議、瀏覽器原生可連、JSON 版也能 curl。它放寬了「端到端 HTTP/2 加 trailers」這組約束、代價是離開純 gRPC 生態(Connect 是 Buf 自家協議)。所以部署邊界不是「要 proto 就得吞下整組 gRPC 約束」的二選一 —— 要 proto 契約與 codegen、但消費端有瀏覽器或過不了 HTTP/2 的中間層時、Connect 這格比硬架 gRPC-Web proxy 省事。

debug 可及性：cURL 測試

介面上線後會被 on-call 的人徒手戳、這個場景在效率比較裡沒有位置、卻是 gRPC 收利息的地方。這位獨立實踐者提出一個可操作的判準 ——「傳一個 cURL 範例給朋友」測試：一個 HTTP+JSON endpoint 可以貼一行 curl 讓對方立刻重現、gRPC 的 binary protobuf over HTTP/2 做不到、要對方裝 client、載 proto、才能發一個請求。這個差距在正常運作時看不到、在半夜排查一個異常請求時變成實質成本。

判準要平衡地用。C32 同時承認生態已修補部分問題：Buf CLI、ConnectRPC、Postman 對 gRPC 的支援讓「徒手戳」不再完全不可行。所以這條軸的現況不是「gRPC 不能 debug」、而是「gRPC 的 debug 需要預先備好工具鏈、不像 HTTP+JSON 零準備可及」。選型判讀：團隊有沒有把這套工具鏈鋪到每個會碰介面的人手上、決定這條軸的實際權重。

這條軸的權重隨組織而變

部署邊界與 debug 可及性的成本不是固定值、跟組織能不能在框架層集中吸收它成反比。有平台團隊統一處理 proxy、觀測、client 工具鏈的組織、這些成本被平台吸收、個別服務作者感受不到；每個介面都要作者自己扛 proxy 與 debug 的小團隊、可及性差的代價會在 on-call 時逐次付還。這條「集中吸收 vs 逐次付還」的判讀、在 內部 RPC 的選型位置 用規模兩端展開。

下一步路由

• gRPC 值得選的組織前提：內部 RPC 的選型位置
• 三軸選型判準：11.2 風格選型總覽
• proto 契約怎麼演進：proto 演進紀律
• 案例原文：模組十一案例庫

集中點的價值：一個規模上限案例

Dropbox 的 Courier 把自製 RPC（HTTP/1.1 加 protobuf）遷移到 gRPC、動機是 multiplexing（單連線多路併發）與雙向 streaming —— 序列化層沒有變動、protobuf 本來就在用（見 11.C31、Dropbox 一手工程紀錄）。遷移之後、他們在這條統一呼叫層上集中疊了四件可靠性能力：mTLS 服務身分、per-method 統計、強制 deadline 傳播、LIFO queue 熔斷。這四件都是「做一次、套全部服務」的 infra-wide 能力 —— 這正是框架層集中點的價值：可靠性策略不必每個服務各寫一遍。

這個案例是規模上限、要當上限讀而非通例。它成立的前提是百萬 RPS（每秒請求數）級的流量與一支能扛遷移的平台團隊。案例本身也留了兩個規模訊號：遷移比初始開發久得多、以及大規模重啟時 TLS 握手成本迫使把 RSA 2048 換成 ECDSA P-256、HTTP/1.1 與 gRPC 還得拆成不同 server 處理。這些踩雷是「有能力集中」的組織才會遇到、也才承擔得起的問題 —— 對沒有平台層集中能力的組織、它們是警訊不是路標。

反向成本：debug 可及性

集中點的價值要跟一項反向成本一起算：gRPC 的操作與 debug 可及性比 HTTP+JSON 差。這條成本在 streaming 與部署邊界 完整展開 —— on-call 不能徒手 curl、瀏覽器要 proxy、工具鏈要預先鋪好。兩相對照就成了選型位置的兩端：一端是 Dropbox 這種有平台團隊統一攤提可及性成本的組織、gRPC 的集中價值遠蓋過 debug 代價；另一端是沒有平台層、每個介面都要作者自己扛操作面的組織、集中點的價值兌現不出來、debug 代價在 on-call 現場一次次付出。

選型位置：落在哪個消費者形狀

把兩端收斂成判準：gRPC 的核心落點是「內部服務、多團隊、且有平台層能集中吸收操作成本」—— 這三者對齊、集中價值才兌現。跨語言是強放大器、不是門檻：schema-first 的跨語言契約確實是 gRPC 的長處、但全 Go 或全 Java 的內部多團隊照樣靠框架層集中拿到 mTLS、deadline 傳播、熔斷這些語言無關的能力、單語言不把 gRPC 排除掉。這一格對應 11.2 消費者形狀軸 的內部服務列。

往核心條件外走、判準就翻向別的風格：對外公開給匿名第三方、可及性與工具生態要求把答案推回 HTTP+JSON；前後端同倉全 TypeScript、契約同步的更省解是 tRPC；本地 process 間雙向低頻、JSON-RPC 的最小訊息層比 gRPC 的 HTTP/2 加 codegen 更貼；要 proto 契約與 codegen、但消費端有瀏覽器或過不了 HTTP/2 的中間層、走 Connect 這類中間協議(見 部署邊界)比純 gRPC 省事。選型的產出是把 gRPC 放對位置、不是全公司統一一種風格。

下一步路由

• 部署約束與 debug 可及性：streaming 與部署邊界
• 三軸選型判準：11.2 風格選型總覽
• 同倉型別共享的對照路線：tRPC 型別共享
• 案例原文：模組十一案例庫