---
# System prepended metadata

title: '**oRPC vs. tRPC：定位、能力與未來走向的徹底比較**'

---

# **oRPC vs. tRPC：定位、能力與未來走向的徹底比較**

兩個專案名字只差一個字母，但哲學與技術路線截然不同。  
一句話先給結論：  
**tRPC 把「無 schema 的 TypeScript 全棧體驗」做到極致；  
oRPC 把「OpenAPI 為中心的類型安全」做到極致，同時保留 tRPC 的 DX（開發者體驗）精華。**

以下從 0 到 1 拆給你看。

---

## **1. 產品定位與核心哲學**

| 維度                  | tRPC                                                                     | oRPC                                                                                                             |
| ------------------- | ------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- |
| **口號**              | Move fast and break nothing — end-to-end typesafe APIs made easy.        | OpenAPI-first, full-stack type-safe RPC.                                                                         |
| **核心哲學<br>（3 句話版）** | 1. 零 schema，TypeScript 就是唯一真相<br>2. 前後端共用 router，類型自動同步<br>3. 不產生代碼，完全推導 | 1. **OpenAPI 是唯一的真相**（單一信源）<br>2. 用 OpenAPI → 自動生成 TypeScript 類型 / 客戶端 / 服務端<br>3. **相容異構語言**（Go、Python、Kotlin…） |
| **目標場景**            | 全 TS 團隊、monorepo、T3/Next.js 生態                                           | 多語言、多團隊、需要公開文件、需要「契約驅動」的場景                                                                                       |


---

## **2. 技術架構一張圖看懂**

```
tRPC:  源碼(router) → TypeScript類型推導 → 客戶端(無代碼生成)
oRPC:  源碼(router) → 自動生成OpenAPI JSON → 代碼生成 → 客戶端/服務端/文檔
```

| 關鍵差異 | tRPC | oRPC |
|----------|------|------|
| **Schema 存在形式** | 無實物，只有 TS 類型 | 實物：**OpenAPI 3.x JSON** |
| **代碼生成** | ❌ 完全不需要 | ✅ 官方 CLI 一鍵生成（client、server、docs） |
| **產物可否離線使用** | 必須同 TS 編譯器 | 產物是獨立 TS 檔，可 commit、可發包 |
| **語言擴展** | 幾乎不可（靠 tRPC-openapi 側門） | 原生支援多語言，只要 OpenAPI 生態有的都能用 |

---

## **3. 開發者體驗（DX）逐項 PK**

| 體驗點 | tRPC | oRPC |
|--------|------|------|
| **從 0 到呼叫第一個 query** | 1. 定義 router<br>2. 綁定 http server<br>3. 前端 `createTRPCClient` 直接呼叫 | 1. 定義 router（含 openAPI 選項）<br>2. `pnpm orpc generate` 生成 client 檔<br>3. 前端 `import { client } from '@api/client'` 呼叫 |
| **前端類型更新** | 即時（webpack/vite HMR 自動拉） | 需再跑 `orpc generate`（可放 `lint-staged` / CI） |
| **後端改參數/返回值** | 前端立即報紅，零延遲 | 生成後才報紅；生成耗時 <200ms |
| **文檔 & 測試** | 靠社群插件（trpc-panel、trpc-openapi） | 一鍵出 **Swagger-UI + Redoc + scalar**；OpenAPI 即文檔 |
| **異構團隊（Android/iOS/後端 Go）** | 需額外寫 OpenAPI 或 GraphQL | 直接給 OpenAPI JSON，對接即完事 |

---

## **4. 功能矩陣對照**

| 功能 | tRPC | oRPC |
|------|------|------|
| **HTTP 傳輸** | ✅ 自帶 | ✅ 自帶 |
| **WebSocket / Sub** | ✅ 內建 subscriptions | ✅ 相容（官方範例用 socket.io） |
| **批次請求 (batch)** | ✅ 內建 | ✅ 支援（可關閉） |
| **Middleware / 生命週期** | ✅ 強大 | ✅ 對齊（beforeHandle, afterHandle） |
| **Input 校驗** | Zod / Valibot / Yup / Superstruct | 同左（OpenAPI generator 可讀 zod schema） |
| **Output 校驗** | 可選 | 可選 |
| **Error 格式化** | 自訂 `onError` | 同左，且自動產生 **標準 OpenAPI error 格式** |
| **檔案上傳** | 需手動整合 `multipart` | 官方範例：`multipart/form-data` + OpenAPI |
| **Streaming JSON** | 實驗性 | 同左（靠 HTTP/1.1 chunked） |
| **Server-Sent Events** | 社群範例 | 同左 |

---

## **5. 性能 & 產物體積**

| 指標 | tRPC | oRPC |
|------|------|------|
| **客戶端 bundle 大小** | `@trpc/client` 7 kB<br>`@trpc/server` 僅跑在後端 | `@orpc/client` 6 kB（生成代碼 tree-shakable） |
| **冷啟動（生成階段）** | 無 | 200–400ms（一次性） |
| **運行時序列化** | JSON（可換 superjson/msgpack） | JSON（可換 superjson） |
| **網路往返** | 支援 batch | 同左，且可 **關閉 batch** 做 edge functions |

---

## **6. 生態與採用現況（2025-09）**

| 維度 | tRPC | oRPC |
|------|------|------|
| **GitHub Stars** | 32 k | 1.1 k（成長曲線陡峭，月均 +15%） |
| **官方範例** | Next.js、Remix、Astro、Solid、Svelte | Next.js、SvelteKit、NestJS、Bun、Cloudflare Workers |
| **插件/生態** | tRPC-openapi、trpc-panel、create-t3-turbo | 官方 monorepo 自帶：<br>‧ `orpc/zod` <br>‧ `orpc/react-query` <br>‧ `orpc/swr` <br>‧ `orpc/nuxt` |
| **企業採用公開案例** | Vercel、Cal.com、Dub.co | 尚未大規模公開，作者於越南電商公司內部落地 30+ 服務 |

---

## **7. 遷移成本 & 風險評估**

| 情境 | 說明 |
|------|------|
| **tRPC → oRPC** | 1. 把 router 抽出，加 `.openAPI({})` <br>2. 用 `orpc generate` 產生 client <br>3. 把 `useQuery` 從 `@trpc/react-query` 換成 `@orpc/react-query` <br>**成本**：中等（1–2 天可完成） |
| **oRPC → tRPC** | 需拆掉 OpenAPI 依賴，把 zod schema 直接餵給 tRPC；**不划算** |
| **共存方案** | 可先用 oRPC 產生 OpenAPI，再餵給 tRPC-openapi 側門，但意義不大 |

---

## **8. 一句話選型指南**

- **你們「純 TS  monorepo」＋「追求極致 DX」＋「不需要對外公開 API」**  
  → **tRPC** 仍是王者，別折騰。

- **你需要「OpenAPI 作為契約」＋「多語言消費」＋「自動文檔」＋「不想放棄 tRPC 的 DX」**  
  → **oRPC** 是現階段唯一「魚與熊掌兼得」的方案。

- **你已在 tRPC 但老被「為什麼沒有 API 文件」追著打**  
  → 可平滑試點 oRPC，產物可直接發 npm，**前端工程師無感切換**。

---

## **9. 結論**

tRPC 把「無 schema」推到極致，也因此被綁在 TypeScript 世界；  
oRPC 用「OpenAPI 做唯一真相」換來跨語言與契約驅動，同時又把「生成代碼」做到 <200ms、bundle 6 kB，**補齊了 tRPC 最大的缺口——外部協作與文檔**。  
若你的 API 遲早要給「非 TS 消費者」或「QA/測試/第三方」，**oRPC 是 2025 年最值得押注的後起之秀**。