如果你跟我一樣這幾年在各種全棧方案之間反復橫跳——REST、GraphQL、BFF——最近又被“前后端類型一體”這個思路勾住了那你一定沒少在技術(shù)雷達上見過 T3 Stack 的名字。我手上代號叫 t3code 的內(nèi)部項目就是決定用這套方案重寫核心業(yè)務系統(tǒng)后落地的結(jié)果。這篇文章不打算做 T3 的科普百科而是把我從選型、搭建到上線的完整過程拆開講明白重點說清楚 tRPC 端到端類型推導的底層邏輯以及生產(chǎn)環(huán)境里那些官方文檔不會寫的細節(jié)。如果你正在猶豫要不要上 T3或者項目已經(jīng)跑起來但遇到了一些詭異問題這篇都值得你看下去。T3 Stack 本身不是一個框架而是一套基于 TypeScript 的技術(shù)棧組合Next.js 負責應用框架tRPC 負責 API 層Tailwind CSS 負責樣式Prisma 負責數(shù)據(jù)庫訪問NextAuth 負責認證。它不復雜但它的取舍非常明確在這個棧里類型安全是一等公民任何一層斷裂都會在編譯期被攔下來。下面我按自己的實操過程來講從選型邏輯講到部署運維。1. 從REST到tRPCT3生態(tài)為什么把類型安全放在第一位1.1 傳統(tǒng)全棧開發(fā)的類型斷裂痛點先講一個絕大多數(shù)全棧團隊都經(jīng)歷過的場景后端同學把訂單接口的返回字段從createTime改成了createdAt數(shù)據(jù)庫和接口文檔都更新了但前端還在用createTime取數(shù)據(jù)。由于前端調(diào)用是通過fetch加手寫interface實現(xiàn)的TypeScript 根本不會報錯直到聯(lián)調(diào)時頁面上出現(xiàn)一排undefined你才發(fā)現(xiàn)問題。這就是典型的“類型斷裂”。在傳統(tǒng) REST 架構(gòu)里前端和后端明明是同一撥人維護卻硬生生過出了跨部門協(xié)作的即視感。為了彌補這個裂縫團隊常見的做法是引入 OpenAPI讓后端從接口框架里自動生成 spec 文件前端再通過 openapi-typescript 這類工具生成類型。這條路能走但它有幾個繞不開的成本接口文檔可能滯后、生成器配置項復雜、多服務之間的 spec 版本管理也是爛攤子。我之前的項目就吃過 OpenAPI 的虧。后端升級了一個依賴自動生成的 spec 里某個字段被波及前端類型生成后到處報錯最后發(fā)現(xiàn)是“文檔本身沒錯但生成的類型文件沒同步提交”的烏龍。類型安全這件事在 REST 體系里靠約定和工具鏈去補總有一種打完補丁又漏水的別扭感。1.2 tRPC的類型推導魔法類型如何從后端流到前端tRPC 采取的思路和 REST 完全不同它不定義協(xié)議層也不要 schema 文件而是直接把 TypeScript 的類型系統(tǒng)當成通信協(xié)議。你只需要在后端定義一個 router前端通過createTRPCReactAppRouter()引入這個 router 的類型之后調(diào)用api.todo.list.useQuery()返回值、入?yún)ⅰ㈠e誤類型都會被自動推導出來。這里的關(guān)鍵機制是 TypeScript 的泛型推斷。AppRouter的類型被傳給了 React hooks 封裝層所有 procedure 的類型信息都在編譯期被展開。它不是靠代碼生成器把后端類型“復制”到前端而是把類型定義本身作為唯一事實來源。后端改了輸入?yún)?shù)的結(jié)構(gòu)前端代碼里對應調(diào)用點直接編譯報錯你不用翻接口文檔不用刷新類型文件回歸測試的意愿和鏈路都清晰得多。我第一次在項目里落地 tRPC 時被一個場景震撼到后端給某個 mutation 的輸入加了一個必填字段我甚至沒有打開前端編輯器只聽到旁邊同事喊了一句“這個接口掛了”回頭一看是編譯報錯指出了哪幾個頁面在調(diào)用。這種體驗在傳統(tǒng) REST 鏈路里幾乎不可能出現(xiàn)。1.3 Next.js在T3里的角色API路由與服務端調(diào)用兩條路架構(gòu)里為什么選 Next.js 而不是 Vite Express因為 Next.js 同時提供了兩條通向后端邏輯的路徑一條是常規(guī)的 HTTP API 路由src/app/api/trpc/[trpc]/route.ts瀏覽器里的客戶端組件通過它發(fā)起請求另一條是服務端組件里直接調(diào)用 tRPC 的 caller不需要發(fā)起網(wǎng)絡請求就能執(zhí)行后端邏輯并且全程保留類型。這個設計非常務實。對于需要 SEO、首次渲染數(shù)據(jù)的場景你在服務端組件里直接caller.todo.list()取數(shù)據(jù)不需要額外封裝一個頁面接口對于交互密集的場景客戶端組件通過 hooks 調(diào)用同一套 procedure。兩條路共享同一個 router 定義、同一套 Zod 校驗邏輯不會出現(xiàn)“服務端渲染用的是一套邏輯、瀏覽器交互用的是另一套”的分叉現(xiàn)象。2. 用T3搭建一個最小可用的t3code項目骨架2.1 初始化create-t3-app的交互選項怎么選T3 官方提供了 create-t3-app 腳手架命令很簡單pnpm create t3-applatest t3code交互過程會問你是否啟用 App Router、Tailwind、Prisma、tRPC、NextAuth以及是否需要 Docker Compose 開發(fā)環(huán)境。如果你是給現(xiàn)有項目做技術(shù)改造我建議第一次初始化還是全部勾選先把完整鏈路跑通。即使有些能力暫時用不到保留默認結(jié)構(gòu)也能讓你以后加功能時不必臨時鋪管道。初始化完成后腳手架會自動生成一套可運行的項目包括 Prisma client、認證配置、tRPC 的 root router、React Query 的 Provider 封裝。我個人建議用 pnpm 而不是 npm因為 T3 生態(tài)里很多包對依賴提升的版本很敏感pnpm 的嚴格 node_modules 結(jié)構(gòu)能少出很多“幽靈依賴”問題。2.2 目錄結(jié)構(gòu)核心trpc.ts、root.ts、routers與API路由T3 項目的 tRPC 相關(guān)目錄結(jié)構(gòu)大致如下src/ app/ api/trpc/[trpc]/route.ts # HTTP入口 server/ api/ trpc.ts # context、router工廠、procedure定義 root.ts # 合并所有routers routers/ todo.ts # 業(yè)務router trpc/ server.ts # server端helper react.ts # 客戶端hooks封裝 server/ db.ts # Prisma client單例 auth.ts # NextAuth配置trpc.ts是核心工廠文件。它定義了createTRPCContext這是每次請求都會執(zhí)行的環(huán)境初始化函數(shù)通常用來創(chuàng)建數(shù)據(jù)庫連接和讀取會話信息它定義了createTRPCRouter和publicProcedure如果需要登錄校驗就定義protectedProcedure在中間件里檢查 session。root.ts負責把所有業(yè)務 router 合并成一個appRouter并導出它的類型。記住一個原則業(yè)務 router 不要直接修改trpc.ts而是放在routers/目錄下按領(lǐng)域拆分。這樣項目變大后root 里只是多掛幾個模塊不會出現(xiàn)一個上千行的 router 文件。2.3 跑通一條完整鏈路數(shù)據(jù)庫定義到組件調(diào)用我拿一個最簡單的 Todo 功能來復現(xiàn)全鏈路因為它的邏輯足夠小但能展示 T3 每一層的職責。先在prisma/schema.prisma里定義模型model Todo { id Int id default(autoincrement()) title String completed Boolean default(false) createdAt DateTime default(now()) userId String }然后寫 todo routerimport { z } from zod; import { createTRPCRouter, protectedProcedure } from ~/server/api/trpc; export const todoRouter createTRPCRouter({ list: protectedProcedure.query(async ({ ctx }) { return ctx.db.todo.findMany({ orderBy: { createdAt: desc }, }); }), create: protectedProcedure .input(z.object({ title: z.string().min(1) })) .mutation(async ({ ctx, input }) { return ctx.db.todo.create({ data: { title: input.title, userId: ctx.session.user.id }, }); }), });前端組件里調(diào)用use client; import { api } from ~/trpc/react; export function TodoList() { const utils api.useUtils(); const { data: todos } api.todo.list.useQuery(); const createTodo api.todo.create.useMutation({ onSuccess: () utils.todo.list.invalidate(), }); return ( ul {todos?.map((todo) li key{todo.id}{todo.title}/li)} /ul ); }這段代碼里最值得琢磨的是onSuccess里那一行utils.todo.list.invalidate()。T3 默認集成了 TanStack QuerytRPC 的 hooks 底層就是 Query 的封裝。mutation 成功后你需要主動讓相關(guān) query 失效這樣它會重新拉取數(shù)據(jù)。不理解這一點很多人會在列表不刷新時給后端加多余的 “返回最新列表” 邏輯走了彎路。3. 生產(chǎn)環(huán)境最容易翻車的三個環(huán)節(jié)認證、SSR與部署3.1 NextAuth與tRPC的組合context與protectedProcedureT3 默認用 NextAuth 做認證。理論上它和 tRPC 的集成很自然在createTRPCContext里調(diào)用getServerAuthSession()把 session 塞進 context之后每個 procedure 都能訪問ctx.session。但實際落地有幾個細節(jié)很容易踩。第一session.user.id默認并不存在。NextAuth 的 session 類型默認只有name、email、image需要你自己聲明模塊擴充才能拿到用戶 ID。很多新手在protectedProcedure里寫ctx.session.user.id報錯第一反應是去找 Prisma 的問題其實是類型聲明沒補。第二不要在 session 里塞大對象。我見過有人圖省事把整個 user 記錄包括密碼哈希、手機號、內(nèi)部備注塞進 JWT然后所有頁面接口都能拿到它。這既是安全風險也是性能問題因為 JWT 每次請求都要帶在 cookie 里。正確做法是 session 里只放用戶 ID 和基本展示信息業(yè)務數(shù)據(jù)在 procedure 里通過 ID 現(xiàn)查。第三protectedProcedure的處理。我建議用中間件統(tǒng)一封裝不要在每個 router 里手動判斷const enforceUserIsAuthed t.middleware(({ ctx, next }) { if (!ctx.session?.user) { throw new TRPCError({ code: UNAUTHORIZED }); } return next({ ctx: { session: { ...ctx.session, user: ctx.session.user } } }); }); export const protectedProcedure t.procedure.use(enforceUserIsAuthed);這樣后續(xù)所有需要登錄的接口直接protectedProcedure.query()校驗邏輯不會散落各處。3.2 服務端組件里調(diào)用tRPC的兩種姿勢App Router 下服務端組件消費 tRPC 有兩種常見姿勢。第一種是直接調(diào)用 caller。在服務端組件里用createCallerFactory創(chuàng)建調(diào)用器傳入 context然后直接執(zhí)行 procedureimport { createCaller } from ~/server/api/root; import { createTRPCContext } from ~/server/api/trpc; const caller createCaller( await createTRPCContext({ headers: await headers() }) ); const todos await caller.todo.list();這種方式的優(yōu)點是零網(wǎng)絡開銷、類型完整。缺點是如果你的頁面同時有客戶端交互組件服務端拿到的數(shù)據(jù)沒法直接傳給客戶端組件因為客戶端組件不能接收非可序列化對象傳類型也容易斷裂。第二種姿勢配合 React Query 做 hydration。在服務端用createServerSideHelpers預取數(shù)據(jù)并dehydrate然后在客戶端根組件用HydrationBoundary包裹。這樣服務端先拿到數(shù)據(jù)客戶端接管后不會重復請求。代價是你要多配置一層 hydration 模板而且初次上手時會覺得不那么直觀。我個人的建議是整頁以展示為主的服務端組件用 caller交互復雜、需要客戶端狀態(tài)的區(qū)域走 hydration。兩種姿勢混用的時候注意邊界要清晰不要在一個頁面里既用 caller 取數(shù)據(jù)、又用同樣的查詢 key 做客戶端預取否則容易出現(xiàn)重復請求的假象。3.3 部署階段Prisma客戶端、遷移與連接池的坑部署是 T3 項目最容易藏坑的地方尤其圍繞 Prisma。先說prisma generate。Postinstall 腳本里一定要加上它因為很多部署平臺安裝依賴后不會自動執(zhí)行 Prisma 的代碼生成。少了這一步項目啟動時會報 “PrismaClient is unable to run in this environment” 之類的錯誤場面非常迷惑。{ scripts: { postinstall: prisma generate } }再說數(shù)據(jù)庫遷移。開發(fā)環(huán)境你大可以prisma db push直接把 schema 推到數(shù)據(jù)庫但生產(chǎn)環(huán)境規(guī)范做法是生成遷移文件、走prisma migrate deploy。這個命令只執(zhí)行未被跟蹤的遷移文件不會做任何交互適合 CI/CD 鏈路。還有一個很多人遇到過的部署平臺報錯在 Docker Alpine 鏡像里運行 Prisma。由于 Alpine 的 C 庫是 musl 而不是 glibcPrisma 引擎需要顯式聲明二進制目標。如果不想折騰可以直接在 schema.prisma 里指定generator client { provider prisma-client-js binaryTargets [native, linux-musl-openssl-3.0.x] }連接池管理也是容易被忽視的點。serverless 環(huán)境下每個請求都會創(chuàng)建數(shù)據(jù)庫連接不加限制會打爆 PostgreSQL 的連接數(shù)上限。我一般在數(shù)據(jù)庫連接串里顯式加連接池并給 serverless 函數(shù)配置頭部Connection頭不緩存確保每個冷啟動實例都能拿到正確的數(shù)據(jù)庫連接。4. 和主流方案的對比T3不是銀彈但它的取舍很清晰4.1 T3 vs RESTOpenAPI文檔與類型誰更可靠有不少團隊會問我們現(xiàn)在的 REST OpenAPI 已經(jīng)跑得好好的為什么要換我會說如果你的 API 要暴露給多個語言生態(tài)的客戶端或者有嚴格的第三方接入治理要求REST OpenAPI 仍然是正確選擇。OpenAPI 能生成人類可讀的文檔還能驅(qū)動多語言 SDK這是一套面向生態(tài)的規(guī)范T3 的 tRPC 在這種場景下反而不夠格。但如果 API 消費者只有自家的前端T3 的優(yōu)勢非常明顯。在 REST 鏈路里OpenAPI 文檔和接口實現(xiàn)是兩個獨立產(chǎn)物需要靠流程保證它們一致在 tRPC 鏈路里router 定義本身就是文檔不存在“文檔落后于實現(xiàn)”的中間狀態(tài)。團隊越小、前后端越統(tǒng)一越應該傾向于后者。4.2 T3 vs GraphQLschema先行與代碼先行的路線之爭GraphQL 的思路是 schema 先行你定義type Todo { ... }、定義 query 和 mutation然后前后端都圍繞這個 schema 工作。它的優(yōu)勢在于客戶端能夠按需取字段復雜聚合查詢的表達能力很強。但代價是你需要維護一套 schema 語言理解 resolver、fragment、cache 這些概念團隊協(xié)作成本不低。T3 走的是代碼先行。router 里寫 TypeScript 函數(shù)類型自然生成沒有額外的 schema DSL。對于大多數(shù)內(nèi)部系統(tǒng)按需取字段的需求其實沒那么強反而是“把類型安全無損地從數(shù)據(jù)庫帶到前端”更值錢。我觀察到的趨勢是很多團隊用 GraphQL 僅僅只是為了拿類型生成但 tRPC 用更輕的方式做到了同樣的事。4.3 什么情況下我建議你別碰T3 Stack我自己折騰完 t3code 項目后對它的局限性也有清醒認識。下面這幾種情況我不建議上 T3。第一你的客戶端不全是 Web。如果有 iOS 原生、Android 原生直接調(diào)用后端的場景tRPC 那套類型安全在非 TS 語言里基本不存在收益。雖然 tRPC 有 HTTP 客戶端可以調(diào)用但你會失去最大賣點同時還要額外處理兼容層不如直接 REST。第二團隊成員對 TypeScript 掌握不牢。tRPC 的高度類型安全是把雙刃劍類型報錯時新手很容易懵圈看不懂泛型推導鏈。如果團隊里有人只會寫 any那 T3 的優(yōu)勢會蕩然無存反而變成維護負擔。第三你需要做純靜態(tài)站點。T3 Stack 默認綁定 Next.js對純靜態(tài)站的來說太重了這時候上 Astro 或者直接寫 Markdown 生成器是更合理的選擇。還有一個容易被忽略的邊界tRPC 的調(diào)試鏈路不如 REST 直觀。在瀏覽器 DevTools 里你能看到請求發(fā)往/api/trpc/todo.list但 payload 是壓縮過的手動構(gòu)造請求也不方便。所以對外調(diào)試工具、或者頻繁需要 curl 驗證的場景T3 會給你帶來額外摩擦。5. 團隊落地t3code后的體驗數(shù)字、協(xié)作與后續(xù)擴展5.1 聯(lián)調(diào)時間顯著縮短類型即契約的工程收益t3code 項目重構(gòu)前后對比最直觀的變化是聯(lián)調(diào)時間。之前我們一個訂單模塊的前后端聯(lián)調(diào)涉及狀態(tài)流轉(zhuǎn)、金額計算、時間格式轉(zhuǎn)換前后端對完字段對格式對完格式對邊界兩到三天很正常。重構(gòu)到 T3 之后同樣的模塊前后端是同一個人或者同一個小組維護后端改字段前端編譯直接報錯接口的出入?yún)㈩愋驮诰庉嬈骼锞褪强梢姷牟恍枰獊砘厍袚Q文檔頁面。我們內(nèi)部做過一次粗測一個中等復雜度的 CRUD 模塊從開發(fā)到提測從原來的約 5 個工作日壓縮到 3 天左右節(jié)省的時間大多花在“不需要反復確認接口定義”。當然這不全是 T3 的功勞也和團隊對 TypeScript 的熟練度提升有關(guān)但類型鏈路完整后“契約”不再存在于聊天記錄里這本身就減少了大量隱性溝通成本。5.2 心智負擔沒有想象中那么大團隊上手實例關(guān)于 T3 的學習成本我的判斷是對已經(jīng)有 Next.js 和 TypeScript 基礎的人兩天內(nèi)能開工對只熟悉傳統(tǒng) MVC 的人一周左右能繞過主要的坑。最大的學習點不是 tRPC 本身而是 TanStack Query 的緩存失效模型。很多第一次寫 T3 的新人會困惑“為什么我 mutation 之后頁面不更新”本質(zhì)是沒有理解invalidate的作用。我建議每個新接觸 T3 的成員都先跑一遍我們總結(jié)的 checklist先取數(shù)query再寫數(shù)mutationmutation 的onSuccess里必帶invalidate如果涉及多個模塊的數(shù)據(jù)聯(lián)動考慮onMutate做樂觀更新。只要把這個心智模型建立起來T3 的使用體驗是順暢的。5.3 后續(xù)擴展方向緩存、批處理與邊緣運行時項目跑順之后可以考慮三個擴展方向。第一是緩存策略。T3 的緩存發(fā)生在 React Query 層staleTime、gcTime的配置能顯著減少后端壓力。服務端渲染場景配合 revalidate 機制可以讓首屏和交互體驗都保持在不錯的水準。第二是批處理。當 router 里的 findMany 每次都查出相同依賴的數(shù)據(jù)時可以考慮引入 dataLoader 模式對資源加載做去重和合并。tRPC 的 context 層很適合掛載這類依賴注入能力。第三是邊緣運行時。T3 官方對 Edge Runtime 的支持一直在推進但 Prisma 的二進制引擎在某些邊緣環(huán)境里仍然是限制條件。如果你有強烈的邊緣渲染需求提前確認 Prisma 的二進制兼容情況不要最后關(guān)頭才發(fā)現(xiàn)。最后再分享一個執(zhí)行層面的建議不管你的目標是個人項目還是團隊遷移不要指望 T3 重構(gòu)一步到位。先挑一個非核心業(yè)務線或者一個內(nèi)部工具用它跑通全家桶觀察兩周再決定鋪不鋪開。我自己就是先拿后臺報表服務做實驗的結(jié)果兩周之后核心團隊已經(jīng)主動要求遷移第二套了。類型安全的體驗是會上癮的但在它上癮之前你更需要的是用一個小項目把那些繞不開的坑都踩一遍。 T3 Stack全棧實踐：tRPC端到端類型安全背后的原理與踩坑
如果你跟我一樣這幾年在各種全棧方案之間反復橫跳——REST、GraphQL、BFF——最近又被“前后端類型一體”這個思路勾住了那你一定沒少在技術(shù)雷達上見過 T3 Stack 的名字。我手上代號叫 t3code 的內(nèi)部項目就是決定用這套方案重寫核心業(yè)務系統(tǒng)后落地的結(jié)果。這篇文章不打算做 T3 的科普百科而是把我從選型、搭建到上線的完整過程拆開講明白重點說清楚 tRPC 端到端類型推導的底層邏輯以及生產(chǎn)環(huán)境里那些官方文檔不會寫的細節(jié)。如果你正在猶豫要不要上 T3或者項目已經(jīng)跑起來但遇到了一些詭異問題這篇都值得你看下去。T3 Stack 本身不是一個框架而是一套基于 TypeScript 的技術(shù)棧組合Next.js 負責應用框架tRPC 負責 API 層Tailwind CSS 負責樣式Prisma 負責數(shù)據(jù)庫訪問NextAuth 負責認證。它不復雜但它的取舍非常明確在這個棧里類型安全是一等公民任何一層斷裂都會在編譯期被攔下來。下面我按自己的實操過程來講從選型邏輯講到部署運維。1. 從REST到tRPCT3生態(tài)為什么把類型安全放在第一位1.1 傳統(tǒng)全棧開發(fā)的類型斷裂痛點先講一個絕大多數(shù)全棧團隊都經(jīng)歷過的場景后端同學把訂單接口的返回字段從createTime改成了createdAt數(shù)據(jù)庫和接口文檔都更新了但前端還在用createTime取數(shù)據(jù)。由于前端調(diào)用是通過fetch加手寫interface實現(xiàn)的TypeScript 根本不會報錯直到聯(lián)調(diào)時頁面上出現(xiàn)一排undefined你才發(fā)現(xiàn)問題。這就是典型的“類型斷裂”。在傳統(tǒng) REST 架構(gòu)里前端和后端明明是同一撥人維護卻硬生生過出了跨部門協(xié)作的即視感。為了彌補這個裂縫團隊常見的做法是引入 OpenAPI讓后端從接口框架里自動生成 spec 文件前端再通過 openapi-typescript 這類工具生成類型。這條路能走但它有幾個繞不開的成本接口文檔可能滯后、生成器配置項復雜、多服務之間的 spec 版本管理也是爛攤子。我之前的項目就吃過 OpenAPI 的虧。后端升級了一個依賴自動生成的 spec 里某個字段被波及前端類型生成后到處報錯最后發(fā)現(xiàn)是“文檔本身沒錯但生成的類型文件沒同步提交”的烏龍。類型安全這件事在 REST 體系里靠約定和工具鏈去補總有一種打完補丁又漏水的別扭感。1.2 tRPC的類型推導魔法類型如何從后端流到前端tRPC 采取的思路和 REST 完全不同它不定義協(xié)議層也不要 schema 文件而是直接把 TypeScript 的類型系統(tǒng)當成通信協(xié)議。你只需要在后端定義一個 router前端通過createTRPCReactAppRouter()引入這個 router 的類型之后調(diào)用api.todo.list.useQuery()返回值、入?yún)ⅰ㈠e誤類型都會被自動推導出來。這里的關(guān)鍵機制是 TypeScript 的泛型推斷。AppRouter的類型被傳給了 React hooks 封裝層所有 procedure 的類型信息都在編譯期被展開。它不是靠代碼生成器把后端類型“復制”到前端而是把類型定義本身作為唯一事實來源。后端改了輸入?yún)?shù)的結(jié)構(gòu)前端代碼里對應調(diào)用點直接編譯報錯你不用翻接口文檔不用刷新類型文件回歸測試的意愿和鏈路都清晰得多。我第一次在項目里落地 tRPC 時被一個場景震撼到后端給某個 mutation 的輸入加了一個必填字段我甚至沒有打開前端編輯器只聽到旁邊同事喊了一句“這個接口掛了”回頭一看是編譯報錯指出了哪幾個頁面在調(diào)用。這種體驗在傳統(tǒng) REST 鏈路里幾乎不可能出現(xiàn)。1.3 Next.js在T3里的角色API路由與服務端調(diào)用兩條路架構(gòu)里為什么選 Next.js 而不是 Vite Express因為 Next.js 同時提供了兩條通向后端邏輯的路徑一條是常規(guī)的 HTTP API 路由src/app/api/trpc/[trpc]/route.ts瀏覽器里的客戶端組件通過它發(fā)起請求另一條是服務端組件里直接調(diào)用 tRPC 的 caller不需要發(fā)起網(wǎng)絡請求就能執(zhí)行后端邏輯并且全程保留類型。這個設計非常務實。對于需要 SEO、首次渲染數(shù)據(jù)的場景你在服務端組件里直接caller.todo.list()取數(shù)據(jù)不需要額外封裝一個頁面接口對于交互密集的場景客戶端組件通過 hooks 調(diào)用同一套 procedure。兩條路共享同一個 router 定義、同一套 Zod 校驗邏輯不會出現(xiàn)“服務端渲染用的是一套邏輯、瀏覽器交互用的是另一套”的分叉現(xiàn)象。2. 用T3搭建一個最小可用的t3code項目骨架2.1 初始化create-t3-app的交互選項怎么選T3 官方提供了 create-t3-app 腳手架命令很簡單pnpm create t3-applatest t3code交互過程會問你是否啟用 App Router、Tailwind、Prisma、tRPC、NextAuth以及是否需要 Docker Compose 開發(fā)環(huán)境。如果你是給現(xiàn)有項目做技術(shù)改造我建議第一次初始化還是全部勾選先把完整鏈路跑通。即使有些能力暫時用不到保留默認結(jié)構(gòu)也能讓你以后加功能時不必臨時鋪管道。初始化完成后腳手架會自動生成一套可運行的項目包括 Prisma client、認證配置、tRPC 的 root router、React Query 的 Provider 封裝。我個人建議用 pnpm 而不是 npm因為 T3 生態(tài)里很多包對依賴提升的版本很敏感pnpm 的嚴格 node_modules 結(jié)構(gòu)能少出很多“幽靈依賴”問題。2.2 目錄結(jié)構(gòu)核心trpc.ts、root.ts、routers與API路由T3 項目的 tRPC 相關(guān)目錄結(jié)構(gòu)大致如下src/ app/ api/trpc/[trpc]/route.ts # HTTP入口 server/ api/ trpc.ts # context、router工廠、procedure定義 root.ts # 合并所有routers routers/ todo.ts # 業(yè)務router trpc/ server.ts # server端helper react.ts # 客戶端hooks封裝 server/ db.ts # Prisma client單例 auth.ts # NextAuth配置trpc.ts是核心工廠文件。它定義了createTRPCContext這是每次請求都會執(zhí)行的環(huán)境初始化函數(shù)通常用來創(chuàng)建數(shù)據(jù)庫連接和讀取會話信息它定義了createTRPCRouter和publicProcedure如果需要登錄校驗就定義protectedProcedure在中間件里檢查 session。root.ts負責把所有業(yè)務 router 合并成一個appRouter并導出它的類型。記住一個原則業(yè)務 router 不要直接修改trpc.ts而是放在routers/目錄下按領(lǐng)域拆分。這樣項目變大后root 里只是多掛幾個模塊不會出現(xiàn)一個上千行的 router 文件。2.3 跑通一條完整鏈路數(shù)據(jù)庫定義到組件調(diào)用我拿一個最簡單的 Todo 功能來復現(xiàn)全鏈路因為它的邏輯足夠小但能展示 T3 每一層的職責。先在prisma/schema.prisma里定義模型model Todo { id Int id default(autoincrement()) title String completed Boolean default(false) createdAt DateTime default(now()) userId String }然后寫 todo routerimport { z } from zod; import { createTRPCRouter, protectedProcedure } from ~/server/api/trpc; export const todoRouter createTRPCRouter({ list: protectedProcedure.query(async ({ ctx }) { return ctx.db.todo.findMany({ orderBy: { createdAt: desc }, }); }), create: protectedProcedure .input(z.object({ title: z.string().min(1) })) .mutation(async ({ ctx, input }) { return ctx.db.todo.create({ data: { title: input.title, userId: ctx.session.user.id }, }); }), });前端組件里調(diào)用use client; import { api } from ~/trpc/react; export function TodoList() { const utils api.useUtils(); const { data: todos } api.todo.list.useQuery(); const createTodo api.todo.create.useMutation({ onSuccess: () utils.todo.list.invalidate(), }); return ( ul {todos?.map((todo) li key{todo.id}{todo.title}/li)} /ul ); }這段代碼里最值得琢磨的是onSuccess里那一行utils.todo.list.invalidate()。T3 默認集成了 TanStack QuerytRPC 的 hooks 底層就是 Query 的封裝。mutation 成功后你需要主動讓相關(guān) query 失效這樣它會重新拉取數(shù)據(jù)。不理解這一點很多人會在列表不刷新時給后端加多余的 “返回最新列表” 邏輯走了彎路。3. 生產(chǎn)環(huán)境最容易翻車的三個環(huán)節(jié)認證、SSR與部署3.1 NextAuth與tRPC的組合context與protectedProcedureT3 默認用 NextAuth 做認證。理論上它和 tRPC 的集成很自然在createTRPCContext里調(diào)用getServerAuthSession()把 session 塞進 context之后每個 procedure 都能訪問ctx.session。但實際落地有幾個細節(jié)很容易踩。第一session.user.id默認并不存在。NextAuth 的 session 類型默認只有name、email、image需要你自己聲明模塊擴充才能拿到用戶 ID。很多新手在protectedProcedure里寫ctx.session.user.id報錯第一反應是去找 Prisma 的問題其實是類型聲明沒補。第二不要在 session 里塞大對象。我見過有人圖省事把整個 user 記錄包括密碼哈希、手機號、內(nèi)部備注塞進 JWT然后所有頁面接口都能拿到它。這既是安全風險也是性能問題因為 JWT 每次請求都要帶在 cookie 里。正確做法是 session 里只放用戶 ID 和基本展示信息業(yè)務數(shù)據(jù)在 procedure 里通過 ID 現(xiàn)查。第三protectedProcedure的處理。我建議用中間件統(tǒng)一封裝不要在每個 router 里手動判斷const enforceUserIsAuthed t.middleware(({ ctx, next }) { if (!ctx.session?.user) { throw new TRPCError({ code: UNAUTHORIZED }); } return next({ ctx: { session: { ...ctx.session, user: ctx.session.user } } }); }); export const protectedProcedure t.procedure.use(enforceUserIsAuthed);這樣后續(xù)所有需要登錄的接口直接protectedProcedure.query()校驗邏輯不會散落各處。3.2 服務端組件里調(diào)用tRPC的兩種姿勢App Router 下服務端組件消費 tRPC 有兩種常見姿勢。第一種是直接調(diào)用 caller。在服務端組件里用createCallerFactory創(chuàng)建調(diào)用器傳入 context然后直接執(zhí)行 procedureimport { createCaller } from ~/server/api/root; import { createTRPCContext } from ~/server/api/trpc; const caller createCaller( await createTRPCContext({ headers: await headers() }) ); const todos await caller.todo.list();這種方式的優(yōu)點是零網(wǎng)絡開銷、類型完整。缺點是如果你的頁面同時有客戶端交互組件服務端拿到的數(shù)據(jù)沒法直接傳給客戶端組件因為客戶端組件不能接收非可序列化對象傳類型也容易斷裂。第二種姿勢配合 React Query 做 hydration。在服務端用createServerSideHelpers預取數(shù)據(jù)并dehydrate然后在客戶端根組件用HydrationBoundary包裹。這樣服務端先拿到數(shù)據(jù)客戶端接管后不會重復請求。代價是你要多配置一層 hydration 模板而且初次上手時會覺得不那么直觀。我個人的建議是整頁以展示為主的服務端組件用 caller交互復雜、需要客戶端狀態(tài)的區(qū)域走 hydration。兩種姿勢混用的時候注意邊界要清晰不要在一個頁面里既用 caller 取數(shù)據(jù)、又用同樣的查詢 key 做客戶端預取否則容易出現(xiàn)重復請求的假象。3.3 部署階段Prisma客戶端、遷移與連接池的坑部署是 T3 項目最容易藏坑的地方尤其圍繞 Prisma。先說prisma generate。Postinstall 腳本里一定要加上它因為很多部署平臺安裝依賴后不會自動執(zhí)行 Prisma 的代碼生成。少了這一步項目啟動時會報 “PrismaClient is unable to run in this environment” 之類的錯誤場面非常迷惑。{ scripts: { postinstall: prisma generate } }再說數(shù)據(jù)庫遷移。開發(fā)環(huán)境你大可以prisma db push直接把 schema 推到數(shù)據(jù)庫但生產(chǎn)環(huán)境規(guī)范做法是生成遷移文件、走prisma migrate deploy。這個命令只執(zhí)行未被跟蹤的遷移文件不會做任何交互適合 CI/CD 鏈路。還有一個很多人遇到過的部署平臺報錯在 Docker Alpine 鏡像里運行 Prisma。由于 Alpine 的 C 庫是 musl 而不是 glibcPrisma 引擎需要顯式聲明二進制目標。如果不想折騰可以直接在 schema.prisma 里指定generator client { provider prisma-client-js binaryTargets [native, linux-musl-openssl-3.0.x] }連接池管理也是容易被忽視的點。serverless 環(huán)境下每個請求都會創(chuàng)建數(shù)據(jù)庫連接不加限制會打爆 PostgreSQL 的連接數(shù)上限。我一般在數(shù)據(jù)庫連接串里顯式加連接池并給 serverless 函數(shù)配置頭部Connection頭不緩存確保每個冷啟動實例都能拿到正確的數(shù)據(jù)庫連接。4. 和主流方案的對比T3不是銀彈但它的取舍很清晰4.1 T3 vs RESTOpenAPI文檔與類型誰更可靠有不少團隊會問我們現(xiàn)在的 REST OpenAPI 已經(jīng)跑得好好的為什么要換我會說如果你的 API 要暴露給多個語言生態(tài)的客戶端或者有嚴格的第三方接入治理要求REST OpenAPI 仍然是正確選擇。OpenAPI 能生成人類可讀的文檔還能驅(qū)動多語言 SDK這是一套面向生態(tài)的規(guī)范T3 的 tRPC 在這種場景下反而不夠格。但如果 API 消費者只有自家的前端T3 的優(yōu)勢非常明顯。在 REST 鏈路里OpenAPI 文檔和接口實現(xiàn)是兩個獨立產(chǎn)物需要靠流程保證它們一致在 tRPC 鏈路里router 定義本身就是文檔不存在“文檔落后于實現(xiàn)”的中間狀態(tài)。團隊越小、前后端越統(tǒng)一越應該傾向于后者。4.2 T3 vs GraphQLschema先行與代碼先行的路線之爭GraphQL 的思路是 schema 先行你定義type Todo { ... }、定義 query 和 mutation然后前后端都圍繞這個 schema 工作。它的優(yōu)勢在于客戶端能夠按需取字段復雜聚合查詢的表達能力很強。但代價是你需要維護一套 schema 語言理解 resolver、fragment、cache 這些概念團隊協(xié)作成本不低。T3 走的是代碼先行。router 里寫 TypeScript 函數(shù)類型自然生成沒有額外的 schema DSL。對于大多數(shù)內(nèi)部系統(tǒng)按需取字段的需求其實沒那么強反而是“把類型安全無損地從數(shù)據(jù)庫帶到前端”更值錢。我觀察到的趨勢是很多團隊用 GraphQL 僅僅只是為了拿類型生成但 tRPC 用更輕的方式做到了同樣的事。4.3 什么情況下我建議你別碰T3 Stack我自己折騰完 t3code 項目后對它的局限性也有清醒認識。下面這幾種情況我不建議上 T3。第一你的客戶端不全是 Web。如果有 iOS 原生、Android 原生直接調(diào)用后端的場景tRPC 那套類型安全在非 TS 語言里基本不存在收益。雖然 tRPC 有 HTTP 客戶端可以調(diào)用但你會失去最大賣點同時還要額外處理兼容層不如直接 REST。第二團隊成員對 TypeScript 掌握不牢。tRPC 的高度類型安全是把雙刃劍類型報錯時新手很容易懵圈看不懂泛型推導鏈。如果團隊里有人只會寫 any那 T3 的優(yōu)勢會蕩然無存反而變成維護負擔。第三你需要做純靜態(tài)站點。T3 Stack 默認綁定 Next.js對純靜態(tài)站的來說太重了這時候上 Astro 或者直接寫 Markdown 生成器是更合理的選擇。還有一個容易被忽略的邊界tRPC 的調(diào)試鏈路不如 REST 直觀。在瀏覽器 DevTools 里你能看到請求發(fā)往/api/trpc/todo.list但 payload 是壓縮過的手動構(gòu)造請求也不方便。所以對外調(diào)試工具、或者頻繁需要 curl 驗證的場景T3 會給你帶來額外摩擦。5. 團隊落地t3code后的體驗數(shù)字、協(xié)作與后續(xù)擴展5.1 聯(lián)調(diào)時間顯著縮短類型即契約的工程收益t3code 項目重構(gòu)前后對比最直觀的變化是聯(lián)調(diào)時間。之前我們一個訂單模塊的前后端聯(lián)調(diào)涉及狀態(tài)流轉(zhuǎn)、金額計算、時間格式轉(zhuǎn)換前后端對完字段對格式對完格式對邊界兩到三天很正常。重構(gòu)到 T3 之后同樣的模塊前后端是同一個人或者同一個小組維護后端改字段前端編譯直接報錯接口的出入?yún)㈩愋驮诰庉嬈骼锞褪强梢姷牟恍枰獊砘厍袚Q文檔頁面。我們內(nèi)部做過一次粗測一個中等復雜度的 CRUD 模塊從開發(fā)到提測從原來的約 5 個工作日壓縮到 3 天左右節(jié)省的時間大多花在“不需要反復確認接口定義”。當然這不全是 T3 的功勞也和團隊對 TypeScript 的熟練度提升有關(guān)但類型鏈路完整后“契約”不再存在于聊天記錄里這本身就減少了大量隱性溝通成本。5.2 心智負擔沒有想象中那么大團隊上手實例關(guān)于 T3 的學習成本我的判斷是對已經(jīng)有 Next.js 和 TypeScript 基礎的人兩天內(nèi)能開工對只熟悉傳統(tǒng) MVC 的人一周左右能繞過主要的坑。最大的學習點不是 tRPC 本身而是 TanStack Query 的緩存失效模型。很多第一次寫 T3 的新人會困惑“為什么我 mutation 之后頁面不更新”本質(zhì)是沒有理解invalidate的作用。我建議每個新接觸 T3 的成員都先跑一遍我們總結(jié)的 checklist先取數(shù)query再寫數(shù)mutationmutation 的onSuccess里必帶invalidate如果涉及多個模塊的數(shù)據(jù)聯(lián)動考慮onMutate做樂觀更新。只要把這個心智模型建立起來T3 的使用體驗是順暢的。5.3 后續(xù)擴展方向緩存、批處理與邊緣運行時項目跑順之后可以考慮三個擴展方向。第一是緩存策略。T3 的緩存發(fā)生在 React Query 層staleTime、gcTime的配置能顯著減少后端壓力。服務端渲染場景配合 revalidate 機制可以讓首屏和交互體驗都保持在不錯的水準。第二是批處理。當 router 里的 findMany 每次都查出相同依賴的數(shù)據(jù)時可以考慮引入 dataLoader 模式對資源加載做去重和合并。tRPC 的 context 層很適合掛載這類依賴注入能力。第三是邊緣運行時。T3 官方對 Edge Runtime 的支持一直在推進但 Prisma 的二進制引擎在某些邊緣環(huán)境里仍然是限制條件。如果你有強烈的邊緣渲染需求提前確認 Prisma 的二進制兼容情況不要最后關(guān)頭才發(fā)現(xiàn)。最后再分享一個執(zhí)行層面的建議不管你的目標是個人項目還是團隊遷移不要指望 T3 重構(gòu)一步到位。先挑一個非核心業(yè)務線或者一個內(nèi)部工具用它跑通全家桶觀察兩周再決定鋪不鋪開。我自己就是先拿后臺報表服務做實驗的結(jié)果兩周之后核心團隊已經(jīng)主動要求遷移第二套了。類型安全的體驗是會上癮的但在它上癮之前你更需要的是用一個小項目把那些繞不開的坑都踩一遍。