前提：同倉 TS-only

型別推導能當契約、靠的是 client 與 server 在同一個 TypeScript 專案裡一起編譯 —— 這是 tRPC 官方 FAQ 自己標明的前提。脫離 monorepo、client 就失去「跟 server 型別一起運作」的保證；唯一的替代是把 backend 型別發成 private npm package 讓 client 依賴。這條前提直接鎖死兩個維度：語言鎖定 TypeScript（型別推導不跨語言）、部署形態鎖定同倉或私有套件。官方也自列一個能力邊界：動態型別輸出做不到、因為它需要 higher-kinded types（型別的型別、TypeScript 型別系統目前還沒到的能力上限）。

落到操作、判斷很乾脆：消費者是不是你自己團隊、跟 server 共用同一個 TS 倉。是 —— tRPC 的零 codegen 是真優勢；不是 —— 前提不成立、優勢歸零。作者社群把這條邊界說得很白：tRPC 無法有效服務公開的第三方 API（見 11.C23 作者自列）。公開 API 的消費者是你控制不了的匿名開發者、他們沒有你的型別、也不會為了呼叫你裝一個 TS 專案 —— 這個形狀要把答案推回 HTTP+JSON。

代價的另一面：契約中介層何時變純開銷

tRPC 的優勢反過來看、是「契約中介層」在單一團隊場景下的成本。一個真實團隊的量化帳可以把這個成本說清楚：Echobind 從 GraphQL 遷到 tRPC 前、同一份資料形狀要在 Prisma、Nexus、GraphQL operations、codegen types、client queries 五層各宣告一次；三層 codegen 產出 8,200 行型別檔、常需重啟編輯器的 language server；依賴體積 GraphQL 側 81.2kb、tRPC 側 23.7kb；遷移後淨減 1,608 行程式碼（見 11.C23）。

這些數字劃出一條判準：schema 這個中介層、在「跨團隊、跨 client 的契約」場景是價值、在「單一團隊同時擁有前後端」場景變純開銷。判準的對象是 schema 的適用場景，跟 tRPC 對 GraphQL 的優劣排名無關。同構 TypeScript 的單團隊、多維護一份 schema 換不到跨方協調的好處、只多出五層宣告要同步。判讀訊號因此是「這份 schema 在協調誰」：協調不同團隊或不同語言的 client、留著；只在協調你自己前後端、它是可以拿掉的中間層。但「單團隊」不直接等於「拿掉」—— 需要對外 API 文件、要跑 contract test、或預期未來出現非 TypeScript 消費者（mobile、第三方）時、schema 仍賺得回維護成本；拿掉的前提是這三者都不成立。同一份帳也出現在 公開 API 的 GraphQL 進退 的適用邊界段、兩章從 GraphQL 與 tRPC 兩側看同一條界線。

schema-first vs inference-first：契約放在相反的地方

tRPC 與 gRPC 的 proto 都在解同一個問題 —— 契約怎麼跨 client 與 server 同步 —— 但把契約放在相反的地方。protobuf 走 schema-first：契約是一份外置的 IDL 檔、跨語言、可用 CI 做 breaking 檢查、代價是要維護檔案與 codegen。tRPC 走 inference-first：契約是型別推導的結果、零 codegen、代價是鎖定單一語言與同倉。這組對照是演進成本這條選型軸的具體兩極：團隊承擔得起「外置 schema 的維護」還是需要「零 codegen 的即時同步」、判準見 11.2。

下一步路由

• 契約外置的對照路線：gRPC proto 演進紀律
• 另一種輕量 RPC 的適用條件：JSON-RPC 的適用條件
• 同一條邊界的 GraphQL 側：公開 API 的 GraphQL 進退
• 三軸選型判準：11.2 風格選型總覽
• 案例原文：模組十一案例庫

條件組合：什麼時候最小訊息層剛好夠

JSON-RPC 只規定訊息的形狀：一個 request 帶 method、params、id、一個對應的 response、以及沒有 id 的 notification。它不管傳輸（誰負責搬 bytes 由外層決定）、不強制 schema、不要 codegen。這個「少」在對外 web API 是缺點 —— 缺工具生態、缺標準化的錯誤與分頁 —— 但在下面這組條件裡剛好是優點：

• 本地 process 間：傳輸是 stdio 或本機 socket、不需要 HTTP/2 的 multiplexing 與流量控制。
• 雙向且需要 notification：server 要能主動推事件給 client（編輯器的診斷、agent 的進度）、JSON-RPC 的 notification 原生支援這個語意。
• 零 codegen、可自省：工具（編輯器外掛、agent runtime）要能不經 build pipeline 就發一個請求、JSON 純文字可讀、不必先產 client stub。

這組條件下、gRPC 的 HTTP/2 加 codegen 成本全是負資產（此為選型判讀、見下方對照）—— 你付了重量、換不到對應的價值。

JSON-RPC 不限於本地 —— Ethereum 節點的 JSON-RPC API 就是網路遠端、走 HTTP、也不低頻。本篇 scope 到「本地雙向低頻」、是因為那是它明顯勝過 gRPC 的區間、不是 JSON-RPC 的全部適用面。

實證：LSP 與 MCP 都在 JSON-RPC 上加約束

兩份現代協議在這組條件下選了 JSON-RPC、而且都是「在它上面加約束」而非發明新協議 —— 這個做法本身是選型訊號。LSP（編輯器與 language server 的協議）明文用 JSON-RPC 描述 requests、responses、notifications、固定 jsonrpc: "2.0"、外層自訂 Content-Length header 當傳輸框（見 11.C34）。MCP（agent 與工具的協議、2025-06-18 spec）規定所有訊息 MUST follow JSON-RPC 2.0、並在其上收緊約束（request ID 不可為 null、同 session 不可重用）、傳輸支援 stdio 與 HTTP。

這裡有一個引用邊界要標明：兩份 spec 都只陳述「採用 JSON-RPC」這個事實、沒有寫「為什麼選它」的理由段。上一節那組條件是本模組從採用事實反推的判讀、不是 spec 的原話。能直接學的做法是：選一個最小夠用的訊息層、然後在它上面加你自己場景需要的約束（ID 語意、session 規則）、而不是為每個新協議重造訊息結構。

對照：與 gRPC、tRPC 的分工

JSON-RPC 跟 gRPC 服務的是不同 deployment shape：gRPC 落在跨服務、高吞吐、要框架層集中的位置；JSON-RPC 落在本地、雙向、低頻的位置。兩者不是競爭、是消費者形狀這條軸的不同列 —— 判準見 11.2。

還有一個當代共性值得點出：MCP 的 schema 以 TypeScript 為 source of truth、跟 tRPC 用型別系統當契約、都指向「用 TypeScript 型別當契約源頭」的模式。這是觀察到的趨勢共性、不是說兩者可互換 —— MCP 仍是跨語言協議、tRPC 綁單語言。

下一步路由

• 高吞吐跨服務的對照位置：gRPC 內部 RPC 的選型位置
• 型別當契約的同倉路線：tRPC 型別共享
• 三軸選型判準：11.2 風格選型總覽
• 案例原文：模組十一案例庫