1. 從“t3code”這個代號說起它到底指什么第一次看到“t3code”這個詞很多人會一頭霧水。它不像“Python入門”或“React教程”那樣直白更像是一個圈內人才懂的暗號。我最初接觸這個詞是在一個技術社群里有人發(fā)了一句“t3code跑通了”底下跟了一串“求配置”。當時我翻遍了主流搜索引擎能找到的有效信息非常零散大部分是零碎的代碼片段和語焉不詳的討論。后來花了不少時間梳理才慢慢拼出它的全貌。簡單來說t3code是一套圍繞“T3技術棧”展開的代碼組織方式與工程實踐約定。這里的“T3”通常指向一個特定的全棧開發(fā)組合——TypeScript、tRPC、Tailwind CSS再加上一個現代前端框架常見的是Next.js。這套組合在近幾年的獨立開發(fā)者和中小團隊中流行度上升得很快原因很直接它把類型安全從數據庫一路貫穿到前端UI省掉了大量手寫接口類型和聯(lián)調扯皮的時間。而“code”這個后綴強調的是落地層面的代碼結構、目錄約定和復用模式而不是單純的技術選型清單。你可能會問為什么非要給這套東西起個代號我的理解是當一套技術組合的實踐足夠成熟、足夠有辨識度時社區(qū)自然會需要一個簡短的標簽來指代它。就像“LAMP”代表LinuxApacheMySQLPHP一樣t3code代表的是“用T3棧寫出來的、經過工程化沉淀的代碼形態(tài)”。它解決的核心問題是在保證端到端類型安全的前提下如何讓項目結構清晰、模塊邊界明確、新人能快速上手。這篇文章適合誰看如果你正在用或打算用TypeScript做全棧項目如果你厭倦了前后端類型對不齊的煩惱如果你想知道一套成熟的T3項目到底該怎么組織目錄、怎么劃分模塊、怎么處理認證和數據庫那接下來的內容應該對你有用。我會從核心原理講起然后拆解目錄結構、關鍵配置、常見坑點最后分享一些我在實際項目里踩出來的經驗。全文基于我對這類項目的理解和實踐不涉及任何特定平臺的綁定。2. T3棧的底層邏輯為什么這套組合能解決類型安全問題2.1 類型安全的全鏈路是怎么打通的要理解t3code的價值得先搞清楚一個根本問題傳統(tǒng)全棧開發(fā)里類型信息是在哪里斷掉的。假設你用React寫前端用Node.js寫后端數據庫用PostgreSQL。前端定義了一個User接口后端也定義了一個User接口數據庫里還有一張users表。這三處的“User”看起來一樣實際上各寫各的。后端改了一個字段名前端不知道直到運行時接口報錯才發(fā)現。這就是典型的“類型斷裂”。T3棧的思路是讓類型信息從數據庫schema自動流向API層再自動流向客戶端調用處。具體怎么做到的數據庫層用Prisma或Drizzle這類ORM它們能從schema生成TypeScript類型。API層用tRPC它利用TypeScript的泛型推導把后端函數的輸入輸出類型直接暴露給前端。前端調用時編輯器能實時提示參數類型和返回值結構寫錯了立刻標紅。整個過程不需要手寫任何接口類型定義也不需要生成中間文件。我舉個具體的例子。假設后端有一個getUserById的tRPC procedure輸入是{ id: string }返回是User類型。前端這樣調用const { data } trpc.user.getUserById.useQuery({ id: abc123 });此時data的類型會被自動推導為User | undefined。如果你把id寫成數字編輯器會直接報錯。如果后端把返回類型改了前端所有調用處會立刻出現類型錯誤提示。這種“改一處、全鏈路感知”的體驗是T3棧最核心的賣點。2.2 tRPC相比REST和GraphQL的取舍有人會問GraphQL也能做到類型安全為什么還要用tRPC這里涉及一個關鍵的取舍。GraphQL的類型安全依賴于schema定義和代碼生成步驟你需要維護一份SDL然后跑codegen生成前端類型。多了一個中間環(huán)節(jié)就多了一層維護成本。而tRPC完全基于TypeScript的類型推導沒有schema文件沒有代碼生成后端函數即接口定義。對于TypeScript monorepo項目來說這種“零中間層”的體驗非常順滑。當然tRPC也有明顯的局限。它天然綁定TypeScript如果你的客戶端是Swift或Kotlin就用不了。它也不適合對外暴露公共API因為它的類型推導依賴服務端代碼。所以t3code的適用場景很明確前后端都是TypeScript、團隊規(guī)模不大、迭代速度要求高、不需要對外開放API。在這個邊界內它的開發(fā)效率優(yōu)勢非常明顯。2.3 Tailwind和Next.js在其中的角色Tailwind CSS在T3棧里的作用經常被低估。很多人覺得它只是個CSS框架但在t3code的語境下它承擔了“樣式與組件同構”的職責。因為Tailwind的類名直接寫在JSX里組件的樣式和邏輯是綁定在一起的復制一個組件到另一個項目樣式不會丟。這對于快速搭建UI、保持設計一致性很有幫助。Next.js則提供了全棧的運行時基礎。它的API Routes或Server Actions可以承載tRPC的handler它的文件路由系統(tǒng)讓頁面組織變得直觀它的SSR/SSG能力讓首屏性能有保障。更重要的是Next.js的app目錄模式支持React Server Components這意味著部分數據獲取可以放在服務端完成減少客戶端的請求瀑布。T3棧和Next.js的結合本質上是在“類型安全”之外再疊加一層“渲染性能”的優(yōu)化。3. 一個標準t3code項目的目錄骨架長什么樣3.1 頂層目錄的劃分邏輯我見過不少T3項目目錄結構五花八門但跑得順的項目往往遵循一些共同的約定。下面這個結構是我自己反復調整后覺得比較順手的版本├── prisma/ │ ├── schema.prisma │ └── migrations/ ├── src/ │ ├── app/ │ │ ├── (auth)/ │ │ ├── (main)/ │ │ └── api/ │ ├── components/ │ │ ├── ui/ │ │ └── features/ │ ├── server/ │ │ ├── api/ │ │ │ ├── routers/ │ │ │ ├── root.ts │ │ │ └── trpc.ts │ │ ├── auth/ │ │ └── db/ │ ├── lib/ │ ├── styles/ │ └── types/ ├── public/ ├── .env ├── next.config.js ├── tailwind.config.ts └── tsconfig.json這個結構的核心思路是按職責分層而不是按文件類型分層。src/server下面集中放所有服務端代碼包括tRPC路由、認證邏輯、數據庫客戶端。src/app是Next.js的頁面和API入口。src/components放React組件其中ui放通用基礎組件features放業(yè)務組件。src/lib放工具函數和共享邏輯。為什么要把server和app分開因為Next.js的app目錄里既有服務端代碼也有客戶端代碼邊界容易模糊。把tRPC路由和數據庫邏輯單獨抽到server目錄能強制形成一道心理邊界這里的代碼只在服務端運行不要在前端組件里直接import。3.2 tRPC路由的嵌套與合并tRPC的路由組織是t3code里最需要花心思的部分。一個常見的做法是每個業(yè)務領域一個router文件然后在root.ts里合并。// src/server/api/routers/user.ts import { z } from zod; import { createTRPCRouter, protectedProcedure } from ../trpc; export const userRouter createTRPCRouter({ getById: protectedProcedure .input(z.object({ id: z.string() })) .query(async ({ ctx, input }) { return ctx.db.user.findUnique({ where: { id: input.id } }); }), updateProfile: protectedProcedure .input(z.object({ name: z.string().min(1) })) .mutation(async ({ ctx, input }) { return ctx.db.user.update({ where: { id: ctx.session.user.id }, data: { name: input.name }, }); }), });然后在root.ts里合并// src/server/api/root.ts import { createTRPCRouter } from ./trpc; import { userRouter } from ./routers/user; import { postRouter } from ./routers/post; export const appRouter createTRPCRouter({ user: userRouter, post: postRouter, }); export type AppRouter typeof appRouter;這里的關鍵點是AppRouter類型的導出。前端通過import type { AppRouter } from ~/server/api/root拿到這個類型tRPC的client就能自動推導出所有路由的輸入輸出類型。這個類型導入是純類型導入不會把服務端代碼打包進客戶端。3.3 組件目錄的拆分策略components目錄的拆分我踩過坑。一開始我把所有組件都放在一個components文件夾里結果很快就亂了。后來改成兩層ui放無業(yè)務邏輯的通用組件比如Button、Input、Modal、Cardfeatures放帶業(yè)務邏輯的組件比如UserProfile、PostList、CommentForm。這樣拆的好處是ui組件可以跨項目復用它們只依賴props不依賴tRPC或數據庫。features組件可以自由調用tRPC hooks因為它們本來就是業(yè)務的一部分。當你想把某個功能模塊抽成獨立包時features下的目錄可以直接搬走依賴關系清晰。還有一個細節(jié)features下的組件盡量按業(yè)務領域建子目錄比如features/user/、features/post/。每個子目錄里可以放組件、hooks、工具函數形成一個自包含的模塊。這樣當業(yè)務增長時你不會在一個巨大的components文件夾里大海撈針。4. 環(huán)境搭建與核心配置從零跑通第一個t3code項目4.1 初始化項目時最容易忽略的三個配置現在社區(qū)里有現成的腳手架工具可以一鍵生成T3項目但自動生成的東西往往讓人知其然不知其所以然。我建議至少手動過一遍關鍵配置這樣出了問題才知道去哪里找。第一個容易忽略的是tsconfig.json里的路徑別名。T3項目通常用~或指向src目錄這樣import路徑不會出現../../..這種反人類寫法。配置大概長這樣{ compilerOptions: { baseUrl: ., paths: { ~/*: [./src/*] } } }配完之后import { Button } from ~/components/ui/button就能正常解析。但要注意Next.js的app目錄和src目錄的關系需要確認清楚如果app在src下面路徑別名要相應調整。第二個是環(huán)境變量的類型聲明。T3項目通常用t3-oss/env-nextjs這個包來管理環(huán)境變量它能在構建時校驗變量是否存在、格式是否正確。配置在src/env.js里import { createEnv } from t3-oss/env-nextjs; import { z } from zod; export const env createEnv({ server: { DATABASE_URL: z.string().url(), NEXTAUTH_SECRET: z.string().min(1), }, client: { NEXT_PUBLIC_APP_URL: z.string().url(), }, runtimeEnv: { DATABASE_URL: process.env.DATABASE_URL, NEXTAUTH_SECRET: process.env.NEXTAUTH_SECRET, NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL, }, });這樣做的好處是如果忘了配某個環(huán)境變量項目啟動時會直接報錯而不是等到運行時才出現莫名其妙的undefined。第三個是Prisma的客戶端單例模式。在開發(fā)環(huán)境下Next.js的熱重載會反復執(zhí)行模塊代碼如果每次都new PrismaClient()數據庫連接數會迅速耗盡。標準做法是在src/server/db.ts里做全局單例import { PrismaClient } from prisma/client; const globalForPrisma globalThis as unknown as { prisma: PrismaClient | undefined; }; export const db globalForPrisma.prisma ?? new PrismaClient({ log: process.env.NODE_ENV development ? [query, error, warn] : [error], }); if (process.env.NODE_ENV ! production) globalForPrisma.prisma db;這個模式在Prisma官方文檔里有詳細說明但很多新手會忽略導致開發(fā)時數據庫連接報錯。4.2 tRPC上下文與認證的銜接方式tRPC的context是連接認證系統(tǒng)和數據庫的橋梁。在src/server/api/trpc.ts里你需要定義createTRPCContext函數它接收每個請求的原始信息返回一個包含db和session的對象。import { initTRPC, TRPCError } from trpc/server; import { type Session } from next-auth; import { db } from ../db; interface CreateContextOptions { session: Session | null; } export const createTRPCContext async (opts: CreateContextOptions) { return { db, session: opts.session, }; }; const t initTRPC.contexttypeof createTRPCContext().create(); export const createTRPCRouter t.router; export const publicProcedure t.procedure; export const protectedProcedure t.procedure.use(({ ctx, next }) { if (!ctx.session?.user) { throw new TRPCError({ code: UNAUTHORIZED }); } return next({ ctx: { session: { ...ctx.session, user: ctx.session.user }, }, }); });這里的關鍵設計是protectedProcedure。它通過中間件檢查session是否存在如果不存在就拋UNAUTHORIZED錯誤。所有需要登錄的接口都用protectedProcedure定義這樣認證邏輯只寫一次所有路由自動繼承。認證系統(tǒng)本身通常用NextAuth現在叫Auth.js它和tRPC的集成點在于NextAuth負責處理登錄流程和session管理tRPC的context從NextAuth的getServerSession里拿session。兩者通過createTRPCContext的調用處銜接通常在Next.js的API handler里完成。4.3 數據庫schema設計中的類型推導技巧Prisma schema是類型鏈路的起點。你在schema里定義的每個modelPrisma都會生成對應的TypeScript類型。這些類型會通過tRPC的返回類型自動流向客戶端。model Post { id String id default(cuid()) title String content String? published Boolean default(false) authorId String author User relation(fields: [authorId], references: [id]) createdAt DateTime default(now()) updatedAt DateTime updatedAt }這個Postmodel會生成Post類型包含所有字段。當你在tRPC的postRouter里返回一個Post對象時前端拿到的data類型就是Post。如果你在schema里加了一個字段Prisma重新生成后前端所有用到這個類型的地方都會自動更新。有一個技巧值得分享用Prisma的select和include來精確控制返回類型。比如你不想把用戶的密碼哈希返回給前端可以在查詢時用select排除掉。這樣生成的類型里就不會包含敏感字段前端也無法訪問。const user await ctx.db.user.findUnique({ where: { id: input.id }, select: { id: true, name: true, email: true, image: true }, });這樣返回的類型就是{ id: string; name: string | null; email: string; image: string | null }不包含passwordHash。類型安全在這里不僅是防錯也是防泄露。5. 實際開發(fā)中那些文檔不會告訴你的坑5.1 類型推導在復雜嵌套路由下的性能問題tRPC的類型推導很強大但當路由數量增長到幾十個、每個路由的輸入輸出類型都很復雜時TypeScript的類型檢查速度會明顯下降。我遇到過一次項目里有大概四十多個procedure編輯器里每次保存文件都要等三四秒才能出類型提示。后來排查發(fā)現問題出在AppRouter類型的遞歸推導上。解決辦法有兩個。一是拆分router把不相關的業(yè)務路由分到不同的子router里減少單個router的復雜度。二是避免在procedure的返回類型里使用過深的嵌套對象如果某個接口返回的數據結構特別復雜考慮用zod定義明確的輸出schema而不是讓TypeScript去推導。還有一個相關的坑在monorepo里如果前端和后端在不同的package里AppRouter類型的導入路徑會變得很長TypeScript需要跨package解析類型。這種情況下建議在共享package里放一個types.ts只導出AppRouter類型前端從那里導入減少解析開銷。5.2 客戶端組件與服務端組件的邊界混淆Next.js的app目錄引入了React Server Components的概念這給t3code項目帶來了新的復雜度。默認情況下app目錄下的組件是Server Component它們不能使用useState、useEffect也不能調用tRPC的useQueryhook。如果你不小心在Server Component里寫了客戶端代碼會看到一堆莫名其妙的報錯。我的經驗是在文件頂部明確標注use client并且盡量把客戶端組件推到葉子節(jié)點。比如一個頁面整體是Server Component負責數據預取和布局只有需要交互的部分比如一個點贊按鈕、一個表單才抽成Client Component。這樣既能享受Server Component的性能優(yōu)勢又能保留交互能力。tRPC在Server Component里的用法和Client Component不同。Server Component里不能直接用trpc.xxx.useQuery()而是要用createCaller或者api.xxx()的方式直接調用服務端函數。這個切換點容易搞混建議在項目初期就定好規(guī)范哪些頁面用Server Component哪些用Client ComponenttRPC的調用方式分別是什么。5.3 數據庫遷移與類型同步的時序問題Prisma的遷移流程是改schema → 跑prisma migrate dev→ 生成新客戶端 → TypeScript類型更新。這個鏈條里有一個時序問題如果你改了schema但忘了跑遷移或者遷移失敗了但客戶端已經生成類型和數據庫實際結構就會不一致。我踩過一次坑在schema里加了一個可選字段跑遷移時因為數據庫里有臟數據導致遷移失敗但Prisma客戶端已經生成了包含新字段的類型。結果代碼里訪問這個字段時類型檢查通過運行時卻報錯說列不存在。排查了半天才發(fā)現是遷移沒成功。避免這個問題的辦法是每次改schema后先確認遷移成功再重新生成客戶端?？梢栽趐ackage.json里加一個腳本把遷移和生成綁在一起{ scripts: { db:migrate: prisma migrate dev prisma generate } }另外在CI流程里要加一步檢查確保遷移文件和schema是同步的。Prisma提供了prisma migrate diff命令可以對比schema和數據庫的實際差異適合在CI里做校驗。5.4 生產環(huán)境構建時的類型檢查策略Next.js的next build默認會跑TypeScript類型檢查。在t3code項目里這個檢查可能會很慢因為tRPC的類型推導本身就耗時。如果每次構建都全量檢查CI時間會拉得很長。我的做法是在本地開發(fā)時用tsc --noEmit --watch做增量檢查在CI里用next build做全量檢查但把類型檢查單獨抽成一個job。這樣構建和類型檢查可以并行節(jié)省時間。另外可以在next.config.js里配置typescript.ignoreBuildErrors為false默認就是false確保構建時不會跳過類型錯誤。還有一個細節(jié)如果項目里用了zod做輸入校驗確保zod的版本在前后端一致。我曾經遇到過前端用zod 3.21、后端用zod 3.22導致某些校驗行為不一致類型推導也出現了偏差。把zod固定在同一個版本能避免這類問題。6. 從能跑到好用t3code項目的優(yōu)化與擴展思路6.1 用中間件統(tǒng)一處理日志和錯誤tRPC的中間件機制很適合做橫切關注點。除了認證還可以加日志中間件、錯誤上報中間件、性能計時中間件。比如一個簡單的日志中間件const loggerMiddleware t.middleware(async ({ path, type, next }) { const start Date.now(); const result await next(); const duration Date.now() - start; console.log([trpc] ${type} ${path} - ${duration}ms); return result; }); export const loggedProcedure t.procedure.use(loggerMiddleware);然后在需要的地方用loggedProcedure替代publicProcedure。這樣每個請求的耗時和路徑都會被記錄排查性能問題時很有用。錯誤處理也可以用中間件統(tǒng)一格式化。tRPC拋出的TRPCError會帶著錯誤碼和消息傳到前端前端可以用error.message展示用戶友好的提示。但要注意不要把服務端的堆棧信息暴露給前端中間件里可以做一層過濾。6.2 共享邏輯的抽離與復用模式t3code項目里有些邏輯是前后端都要用的比如數據校驗規(guī)則、常量定義、工具函數。這些代碼應該放在src/lib或一個獨立的packages/shared里前后端都從這里導入。一個典型的例子是zod schema。后端用zod校驗輸入前端也可以用同一個schema做表單校驗。這樣校驗規(guī)則只寫一次前后端行為一致。// src/lib/validators/post.ts import { z } from zod; export const createPostSchema z.object({ title: z.string().min(1).max(100), content: z.string().max(5000).optional(), }); export type CreatePostInput z.infertypeof createPostSchema;后端在tRPC procedure里用createPostSchema做input校驗前端在表單提交前用同一個schema做校驗。類型CreatePostInput也可以前后端共用。這種復用模式能顯著減少重復代碼和不一致問題。6.3 性能監(jiān)控與類型安全的平衡類型安全不是免費的它需要TypeScript在編譯時做大量推導。在大型項目里這個開銷會體現在構建時間和編輯器響應速度上。我的經驗是在核心業(yè)務路徑上保持嚴格的類型安全在邊緣邏輯上適當放寬。比如對于數據庫查詢和API接口堅持用Prisma和tRPC的完整類型推導。但對于一些純展示組件、工具函數可以用更寬松的類型甚至用any做臨時過渡但要加注釋說明原因。關鍵是找到一個平衡點既不讓類型系統(tǒng)拖慢開發(fā)速度也不讓類型漏洞導致運行時錯誤。另外可以用tsc --diagnostics查看類型檢查的耗時分布找出最耗時的文件或模塊針對性優(yōu)化。常見的手段包括減少泛型嵌套、避免循環(huán)引用、拆分大型類型定義。6.4 團隊協(xié)作中的代碼規(guī)范約定t3code項目在團隊協(xié)作時最大的挑戰(zhàn)不是技術本身而是約定的一致性。如果每個人對目錄結構、命名方式、路由劃分的理解不同項目很快就會變得難以維護。我建議在項目初期就定好這幾條規(guī)范tRPC路由按業(yè)務領域劃分每個router文件不超過200行組件按ui和features分層features下按業(yè)務建子目錄所有數據庫操作必須通過ctx.db不允許在組件里直接import Prisma客戶端環(huán)境變量必須通過env.js訪問不允許直接讀process.env。這些規(guī)范看起來瑣碎但能避免很多后期重構的痛苦?？梢杂肊SLint的no-restricted-imports規(guī)則來強制某些約定比如禁止從prisma/client直接導入到src/app目錄。工具能做的事就不要靠人的自覺。7. 關于t3code的一些個人體會我在幾個中小型項目里用過T3棧最大的感受是它把“類型安全”從一個口號變成了日常開發(fā)中能感知到的便利。以前改一個字段名要全局搜索替換現在編輯器直接標紅以前前后端聯(lián)調要對著文檔對參數現在類型提示直接告訴你該傳什么。這種體驗上的提升用久了就回不去了。但它也不是銀彈。tRPC的生態(tài)相對年輕遇到一些邊緣場景時文檔和社區(qū)答案不如REST那么豐富。Next.js的版本迭代很快app目錄和pages目錄的混用有時會讓人困惑。Prisma在某些復雜查詢場景下生成的SQL不夠優(yōu)化需要手動調優(yōu)。這些問題都需要在實際項目中慢慢積累經驗。如果你打算開始一個T3項目我的建議是先用腳手架跑通一個最小可用的demo然后花時間理解每個配置項的作用再逐步替換成自己的業(yè)務邏輯。不要一上來就追求完美的目錄結構先讓項目跑起來然后在迭代中調整。類型安全的價值在于長期維護而不是一開始就完美無缺。最后分享一個小技巧在package.json里加一個typecheck腳本用tsc --noEmit做全量類型檢查然后在提交代碼前跑一遍。這個習慣能幫你提前發(fā)現很多類型問題避免把錯誤帶到CI階段。配合編輯器的實時提示基本上能做到“寫的時候就知道對不對”。 t3code工程實踐：T3技術棧全鏈路類型安全與項目結構指南
1. 從“t3code”這個代號說起它到底指什么第一次看到“t3code”這個詞很多人會一頭霧水。它不像“Python入門”或“React教程”那樣直白更像是一個圈內人才懂的暗號。我最初接觸這個詞是在一個技術社群里有人發(fā)了一句“t3code跑通了”底下跟了一串“求配置”。當時我翻遍了主流搜索引擎能找到的有效信息非常零散大部分是零碎的代碼片段和語焉不詳的討論。后來花了不少時間梳理才慢慢拼出它的全貌。簡單來說t3code是一套圍繞“T3技術棧”展開的代碼組織方式與工程實踐約定。這里的“T3”通常指向一個特定的全棧開發(fā)組合——TypeScript、tRPC、Tailwind CSS再加上一個現代前端框架常見的是Next.js。這套組合在近幾年的獨立開發(fā)者和中小團隊中流行度上升得很快原因很直接它把類型安全從數據庫一路貫穿到前端UI省掉了大量手寫接口類型和聯(lián)調扯皮的時間。而“code”這個后綴強調的是落地層面的代碼結構、目錄約定和復用模式而不是單純的技術選型清單。你可能會問為什么非要給這套東西起個代號我的理解是當一套技術組合的實踐足夠成熟、足夠有辨識度時社區(qū)自然會需要一個簡短的標簽來指代它。就像“LAMP”代表LinuxApacheMySQLPHP一樣t3code代表的是“用T3棧寫出來的、經過工程化沉淀的代碼形態(tài)”。它解決的核心問題是在保證端到端類型安全的前提下如何讓項目結構清晰、模塊邊界明確、新人能快速上手。這篇文章適合誰看如果你正在用或打算用TypeScript做全棧項目如果你厭倦了前后端類型對不齊的煩惱如果你想知道一套成熟的T3項目到底該怎么組織目錄、怎么劃分模塊、怎么處理認證和數據庫那接下來的內容應該對你有用。我會從核心原理講起然后拆解目錄結構、關鍵配置、常見坑點最后分享一些我在實際項目里踩出來的經驗。全文基于我對這類項目的理解和實踐不涉及任何特定平臺的綁定。2. T3棧的底層邏輯為什么這套組合能解決類型安全問題2.1 類型安全的全鏈路是怎么打通的要理解t3code的價值得先搞清楚一個根本問題傳統(tǒng)全棧開發(fā)里類型信息是在哪里斷掉的。假設你用React寫前端用Node.js寫后端數據庫用PostgreSQL。前端定義了一個User接口后端也定義了一個User接口數據庫里還有一張users表。這三處的“User”看起來一樣實際上各寫各的。后端改了一個字段名前端不知道直到運行時接口報錯才發(fā)現。這就是典型的“類型斷裂”。T3棧的思路是讓類型信息從數據庫schema自動流向API層再自動流向客戶端調用處。具體怎么做到的數據庫層用Prisma或Drizzle這類ORM它們能從schema生成TypeScript類型。API層用tRPC它利用TypeScript的泛型推導把后端函數的輸入輸出類型直接暴露給前端。前端調用時編輯器能實時提示參數類型和返回值結構寫錯了立刻標紅。整個過程不需要手寫任何接口類型定義也不需要生成中間文件。我舉個具體的例子。假設后端有一個getUserById的tRPC procedure輸入是{ id: string }返回是User類型。前端這樣調用const { data } trpc.user.getUserById.useQuery({ id: abc123 });此時data的類型會被自動推導為User | undefined。如果你把id寫成數字編輯器會直接報錯。如果后端把返回類型改了前端所有調用處會立刻出現類型錯誤提示。這種“改一處、全鏈路感知”的體驗是T3棧最核心的賣點。2.2 tRPC相比REST和GraphQL的取舍有人會問GraphQL也能做到類型安全為什么還要用tRPC這里涉及一個關鍵的取舍。GraphQL的類型安全依賴于schema定義和代碼生成步驟你需要維護一份SDL然后跑codegen生成前端類型。多了一個中間環(huán)節(jié)就多了一層維護成本。而tRPC完全基于TypeScript的類型推導沒有schema文件沒有代碼生成后端函數即接口定義。對于TypeScript monorepo項目來說這種“零中間層”的體驗非常順滑。當然tRPC也有明顯的局限。它天然綁定TypeScript如果你的客戶端是Swift或Kotlin就用不了。它也不適合對外暴露公共API因為它的類型推導依賴服務端代碼。所以t3code的適用場景很明確前后端都是TypeScript、團隊規(guī)模不大、迭代速度要求高、不需要對外開放API。在這個邊界內它的開發(fā)效率優(yōu)勢非常明顯。2.3 Tailwind和Next.js在其中的角色Tailwind CSS在T3棧里的作用經常被低估。很多人覺得它只是個CSS框架但在t3code的語境下它承擔了“樣式與組件同構”的職責。因為Tailwind的類名直接寫在JSX里組件的樣式和邏輯是綁定在一起的復制一個組件到另一個項目樣式不會丟。這對于快速搭建UI、保持設計一致性很有幫助。Next.js則提供了全棧的運行時基礎。它的API Routes或Server Actions可以承載tRPC的handler它的文件路由系統(tǒng)讓頁面組織變得直觀它的SSR/SSG能力讓首屏性能有保障。更重要的是Next.js的app目錄模式支持React Server Components這意味著部分數據獲取可以放在服務端完成減少客戶端的請求瀑布。T3棧和Next.js的結合本質上是在“類型安全”之外再疊加一層“渲染性能”的優(yōu)化。3. 一個標準t3code項目的目錄骨架長什么樣3.1 頂層目錄的劃分邏輯我見過不少T3項目目錄結構五花八門但跑得順的項目往往遵循一些共同的約定。下面這個結構是我自己反復調整后覺得比較順手的版本├── prisma/ │ ├── schema.prisma │ └── migrations/ ├── src/ │ ├── app/ │ │ ├── (auth)/ │ │ ├── (main)/ │ │ └── api/ │ ├── components/ │ │ ├── ui/ │ │ └── features/ │ ├── server/ │ │ ├── api/ │ │ │ ├── routers/ │ │ │ ├── root.ts │ │ │ └── trpc.ts │ │ ├── auth/ │ │ └── db/ │ ├── lib/ │ ├── styles/ │ └── types/ ├── public/ ├── .env ├── next.config.js ├── tailwind.config.ts └── tsconfig.json這個結構的核心思路是按職責分層而不是按文件類型分層。src/server下面集中放所有服務端代碼包括tRPC路由、認證邏輯、數據庫客戶端。src/app是Next.js的頁面和API入口。src/components放React組件其中ui放通用基礎組件features放業(yè)務組件。src/lib放工具函數和共享邏輯。為什么要把server和app分開因為Next.js的app目錄里既有服務端代碼也有客戶端代碼邊界容易模糊。把tRPC路由和數據庫邏輯單獨抽到server目錄能強制形成一道心理邊界這里的代碼只在服務端運行不要在前端組件里直接import。3.2 tRPC路由的嵌套與合并tRPC的路由組織是t3code里最需要花心思的部分。一個常見的做法是每個業(yè)務領域一個router文件然后在root.ts里合并。// src/server/api/routers/user.ts import { z } from zod; import { createTRPCRouter, protectedProcedure } from ../trpc; export const userRouter createTRPCRouter({ getById: protectedProcedure .input(z.object({ id: z.string() })) .query(async ({ ctx, input }) { return ctx.db.user.findUnique({ where: { id: input.id } }); }), updateProfile: protectedProcedure .input(z.object({ name: z.string().min(1) })) .mutation(async ({ ctx, input }) { return ctx.db.user.update({ where: { id: ctx.session.user.id }, data: { name: input.name }, }); }), });然后在root.ts里合并// src/server/api/root.ts import { createTRPCRouter } from ./trpc; import { userRouter } from ./routers/user; import { postRouter } from ./routers/post; export const appRouter createTRPCRouter({ user: userRouter, post: postRouter, }); export type AppRouter typeof appRouter;這里的關鍵點是AppRouter類型的導出。前端通過import type { AppRouter } from ~/server/api/root拿到這個類型tRPC的client就能自動推導出所有路由的輸入輸出類型。這個類型導入是純類型導入不會把服務端代碼打包進客戶端。3.3 組件目錄的拆分策略components目錄的拆分我踩過坑。一開始我把所有組件都放在一個components文件夾里結果很快就亂了。后來改成兩層ui放無業(yè)務邏輯的通用組件比如Button、Input、Modal、Cardfeatures放帶業(yè)務邏輯的組件比如UserProfile、PostList、CommentForm。這樣拆的好處是ui組件可以跨項目復用它們只依賴props不依賴tRPC或數據庫。features組件可以自由調用tRPC hooks因為它們本來就是業(yè)務的一部分。當你想把某個功能模塊抽成獨立包時features下的目錄可以直接搬走依賴關系清晰。還有一個細節(jié)features下的組件盡量按業(yè)務領域建子目錄比如features/user/、features/post/。每個子目錄里可以放組件、hooks、工具函數形成一個自包含的模塊。這樣當業(yè)務增長時你不會在一個巨大的components文件夾里大海撈針。4. 環(huán)境搭建與核心配置從零跑通第一個t3code項目4.1 初始化項目時最容易忽略的三個配置現在社區(qū)里有現成的腳手架工具可以一鍵生成T3項目但自動生成的東西往往讓人知其然不知其所以然。我建議至少手動過一遍關鍵配置這樣出了問題才知道去哪里找。第一個容易忽略的是tsconfig.json里的路徑別名。T3項目通常用~或指向src目錄這樣import路徑不會出現../../..這種反人類寫法。配置大概長這樣{ compilerOptions: { baseUrl: ., paths: { ~/*: [./src/*] } } }配完之后import { Button } from ~/components/ui/button就能正常解析。但要注意Next.js的app目錄和src目錄的關系需要確認清楚如果app在src下面路徑別名要相應調整。第二個是環(huán)境變量的類型聲明。T3項目通常用t3-oss/env-nextjs這個包來管理環(huán)境變量它能在構建時校驗變量是否存在、格式是否正確。配置在src/env.js里import { createEnv } from t3-oss/env-nextjs; import { z } from zod; export const env createEnv({ server: { DATABASE_URL: z.string().url(), NEXTAUTH_SECRET: z.string().min(1), }, client: { NEXT_PUBLIC_APP_URL: z.string().url(), }, runtimeEnv: { DATABASE_URL: process.env.DATABASE_URL, NEXTAUTH_SECRET: process.env.NEXTAUTH_SECRET, NEXT_PUBLIC_APP_URL: process.env.NEXT_PUBLIC_APP_URL, }, });這樣做的好處是如果忘了配某個環(huán)境變量項目啟動時會直接報錯而不是等到運行時才出現莫名其妙的undefined。第三個是Prisma的客戶端單例模式。在開發(fā)環(huán)境下Next.js的熱重載會反復執(zhí)行模塊代碼如果每次都new PrismaClient()數據庫連接數會迅速耗盡。標準做法是在src/server/db.ts里做全局單例import { PrismaClient } from prisma/client; const globalForPrisma globalThis as unknown as { prisma: PrismaClient | undefined; }; export const db globalForPrisma.prisma ?? new PrismaClient({ log: process.env.NODE_ENV development ? [query, error, warn] : [error], }); if (process.env.NODE_ENV ! production) globalForPrisma.prisma db;這個模式在Prisma官方文檔里有詳細說明但很多新手會忽略導致開發(fā)時數據庫連接報錯。4.2 tRPC上下文與認證的銜接方式tRPC的context是連接認證系統(tǒng)和數據庫的橋梁。在src/server/api/trpc.ts里你需要定義createTRPCContext函數它接收每個請求的原始信息返回一個包含db和session的對象。import { initTRPC, TRPCError } from trpc/server; import { type Session } from next-auth; import { db } from ../db; interface CreateContextOptions { session: Session | null; } export const createTRPCContext async (opts: CreateContextOptions) { return { db, session: opts.session, }; }; const t initTRPC.contexttypeof createTRPCContext().create(); export const createTRPCRouter t.router; export const publicProcedure t.procedure; export const protectedProcedure t.procedure.use(({ ctx, next }) { if (!ctx.session?.user) { throw new TRPCError({ code: UNAUTHORIZED }); } return next({ ctx: { session: { ...ctx.session, user: ctx.session.user }, }, }); });這里的關鍵設計是protectedProcedure。它通過中間件檢查session是否存在如果不存在就拋UNAUTHORIZED錯誤。所有需要登錄的接口都用protectedProcedure定義這樣認證邏輯只寫一次所有路由自動繼承。認證系統(tǒng)本身通常用NextAuth現在叫Auth.js它和tRPC的集成點在于NextAuth負責處理登錄流程和session管理tRPC的context從NextAuth的getServerSession里拿session。兩者通過createTRPCContext的調用處銜接通常在Next.js的API handler里完成。4.3 數據庫schema設計中的類型推導技巧Prisma schema是類型鏈路的起點。你在schema里定義的每個modelPrisma都會生成對應的TypeScript類型。這些類型會通過tRPC的返回類型自動流向客戶端。model Post { id String id default(cuid()) title String content String? published Boolean default(false) authorId String author User relation(fields: [authorId], references: [id]) createdAt DateTime default(now()) updatedAt DateTime updatedAt }這個Postmodel會生成Post類型包含所有字段。當你在tRPC的postRouter里返回一個Post對象時前端拿到的data類型就是Post。如果你在schema里加了一個字段Prisma重新生成后前端所有用到這個類型的地方都會自動更新。有一個技巧值得分享用Prisma的select和include來精確控制返回類型。比如你不想把用戶的密碼哈希返回給前端可以在查詢時用select排除掉。這樣生成的類型里就不會包含敏感字段前端也無法訪問。const user await ctx.db.user.findUnique({ where: { id: input.id }, select: { id: true, name: true, email: true, image: true }, });這樣返回的類型就是{ id: string; name: string | null; email: string; image: string | null }不包含passwordHash。類型安全在這里不僅是防錯也是防泄露。5. 實際開發(fā)中那些文檔不會告訴你的坑5.1 類型推導在復雜嵌套路由下的性能問題tRPC的類型推導很強大但當路由數量增長到幾十個、每個路由的輸入輸出類型都很復雜時TypeScript的類型檢查速度會明顯下降。我遇到過一次項目里有大概四十多個procedure編輯器里每次保存文件都要等三四秒才能出類型提示。后來排查發(fā)現問題出在AppRouter類型的遞歸推導上。解決辦法有兩個。一是拆分router把不相關的業(yè)務路由分到不同的子router里減少單個router的復雜度。二是避免在procedure的返回類型里使用過深的嵌套對象如果某個接口返回的數據結構特別復雜考慮用zod定義明確的輸出schema而不是讓TypeScript去推導。還有一個相關的坑在monorepo里如果前端和后端在不同的package里AppRouter類型的導入路徑會變得很長TypeScript需要跨package解析類型。這種情況下建議在共享package里放一個types.ts只導出AppRouter類型前端從那里導入減少解析開銷。5.2 客戶端組件與服務端組件的邊界混淆Next.js的app目錄引入了React Server Components的概念這給t3code項目帶來了新的復雜度。默認情況下app目錄下的組件是Server Component它們不能使用useState、useEffect也不能調用tRPC的useQueryhook。如果你不小心在Server Component里寫了客戶端代碼會看到一堆莫名其妙的報錯。我的經驗是在文件頂部明確標注use client并且盡量把客戶端組件推到葉子節(jié)點。比如一個頁面整體是Server Component負責數據預取和布局只有需要交互的部分比如一個點贊按鈕、一個表單才抽成Client Component。這樣既能享受Server Component的性能優(yōu)勢又能保留交互能力。tRPC在Server Component里的用法和Client Component不同。Server Component里不能直接用trpc.xxx.useQuery()而是要用createCaller或者api.xxx()的方式直接調用服務端函數。這個切換點容易搞混建議在項目初期就定好規(guī)范哪些頁面用Server Component哪些用Client ComponenttRPC的調用方式分別是什么。5.3 數據庫遷移與類型同步的時序問題Prisma的遷移流程是改schema → 跑prisma migrate dev→ 生成新客戶端 → TypeScript類型更新。這個鏈條里有一個時序問題如果你改了schema但忘了跑遷移或者遷移失敗了但客戶端已經生成類型和數據庫實際結構就會不一致。我踩過一次坑在schema里加了一個可選字段跑遷移時因為數據庫里有臟數據導致遷移失敗但Prisma客戶端已經生成了包含新字段的類型。結果代碼里訪問這個字段時類型檢查通過運行時卻報錯說列不存在。排查了半天才發(fā)現是遷移沒成功。避免這個問題的辦法是每次改schema后先確認遷移成功再重新生成客戶端?？梢栽趐ackage.json里加一個腳本把遷移和生成綁在一起{ scripts: { db:migrate: prisma migrate dev prisma generate } }另外在CI流程里要加一步檢查確保遷移文件和schema是同步的。Prisma提供了prisma migrate diff命令可以對比schema和數據庫的實際差異適合在CI里做校驗。5.4 生產環(huán)境構建時的類型檢查策略Next.js的next build默認會跑TypeScript類型檢查。在t3code項目里這個檢查可能會很慢因為tRPC的類型推導本身就耗時。如果每次構建都全量檢查CI時間會拉得很長。我的做法是在本地開發(fā)時用tsc --noEmit --watch做增量檢查在CI里用next build做全量檢查但把類型檢查單獨抽成一個job。這樣構建和類型檢查可以并行節(jié)省時間。另外可以在next.config.js里配置typescript.ignoreBuildErrors為false默認就是false確保構建時不會跳過類型錯誤。還有一個細節(jié)如果項目里用了zod做輸入校驗確保zod的版本在前后端一致。我曾經遇到過前端用zod 3.21、后端用zod 3.22導致某些校驗行為不一致類型推導也出現了偏差。把zod固定在同一個版本能避免這類問題。6. 從能跑到好用t3code項目的優(yōu)化與擴展思路6.1 用中間件統(tǒng)一處理日志和錯誤tRPC的中間件機制很適合做橫切關注點。除了認證還可以加日志中間件、錯誤上報中間件、性能計時中間件。比如一個簡單的日志中間件const loggerMiddleware t.middleware(async ({ path, type, next }) { const start Date.now(); const result await next(); const duration Date.now() - start; console.log([trpc] ${type} ${path} - ${duration}ms); return result; }); export const loggedProcedure t.procedure.use(loggerMiddleware);然后在需要的地方用loggedProcedure替代publicProcedure。這樣每個請求的耗時和路徑都會被記錄排查性能問題時很有用。錯誤處理也可以用中間件統(tǒng)一格式化。tRPC拋出的TRPCError會帶著錯誤碼和消息傳到前端前端可以用error.message展示用戶友好的提示。但要注意不要把服務端的堆棧信息暴露給前端中間件里可以做一層過濾。6.2 共享邏輯的抽離與復用模式t3code項目里有些邏輯是前后端都要用的比如數據校驗規(guī)則、常量定義、工具函數。這些代碼應該放在src/lib或一個獨立的packages/shared里前后端都從這里導入。一個典型的例子是zod schema。后端用zod校驗輸入前端也可以用同一個schema做表單校驗。這樣校驗規(guī)則只寫一次前后端行為一致。// src/lib/validators/post.ts import { z } from zod; export const createPostSchema z.object({ title: z.string().min(1).max(100), content: z.string().max(5000).optional(), }); export type CreatePostInput z.infertypeof createPostSchema;后端在tRPC procedure里用createPostSchema做input校驗前端在表單提交前用同一個schema做校驗。類型CreatePostInput也可以前后端共用。這種復用模式能顯著減少重復代碼和不一致問題。6.3 性能監(jiān)控與類型安全的平衡類型安全不是免費的它需要TypeScript在編譯時做大量推導。在大型項目里這個開銷會體現在構建時間和編輯器響應速度上。我的經驗是在核心業(yè)務路徑上保持嚴格的類型安全在邊緣邏輯上適當放寬。比如對于數據庫查詢和API接口堅持用Prisma和tRPC的完整類型推導。但對于一些純展示組件、工具函數可以用更寬松的類型甚至用any做臨時過渡但要加注釋說明原因。關鍵是找到一個平衡點既不讓類型系統(tǒng)拖慢開發(fā)速度也不讓類型漏洞導致運行時錯誤。另外可以用tsc --diagnostics查看類型檢查的耗時分布找出最耗時的文件或模塊針對性優(yōu)化。常見的手段包括減少泛型嵌套、避免循環(huán)引用、拆分大型類型定義。6.4 團隊協(xié)作中的代碼規(guī)范約定t3code項目在團隊協(xié)作時最大的挑戰(zhàn)不是技術本身而是約定的一致性。如果每個人對目錄結構、命名方式、路由劃分的理解不同項目很快就會變得難以維護。我建議在項目初期就定好這幾條規(guī)范tRPC路由按業(yè)務領域劃分每個router文件不超過200行組件按ui和features分層features下按業(yè)務建子目錄所有數據庫操作必須通過ctx.db不允許在組件里直接import Prisma客戶端環(huán)境變量必須通過env.js訪問不允許直接讀process.env。這些規(guī)范看起來瑣碎但能避免很多后期重構的痛苦?？梢杂肊SLint的no-restricted-imports規(guī)則來強制某些約定比如禁止從prisma/client直接導入到src/app目錄。工具能做的事就不要靠人的自覺。7. 關于t3code的一些個人體會我在幾個中小型項目里用過T3棧最大的感受是它把“類型安全”從一個口號變成了日常開發(fā)中能感知到的便利。以前改一個字段名要全局搜索替換現在編輯器直接標紅以前前后端聯(lián)調要對著文檔對參數現在類型提示直接告訴你該傳什么。這種體驗上的提升用久了就回不去了。但它也不是銀彈。tRPC的生態(tài)相對年輕遇到一些邊緣場景時文檔和社區(qū)答案不如REST那么豐富。Next.js的版本迭代很快app目錄和pages目錄的混用有時會讓人困惑。Prisma在某些復雜查詢場景下生成的SQL不夠優(yōu)化需要手動調優(yōu)。這些問題都需要在實際項目中慢慢積累經驗。如果你打算開始一個T3項目我的建議是先用腳手架跑通一個最小可用的demo然后花時間理解每個配置項的作用再逐步替換成自己的業(yè)務邏輯。不要一上來就追求完美的目錄結構先讓項目跑起來然后在迭代中調整。類型安全的價值在于長期維護而不是一開始就完美無缺。最后分享一個小技巧在package.json里加一個typecheck腳本用tsc --noEmit做全量類型檢查然后在提交代碼前跑一遍。這個習慣能幫你提前發(fā)現很多類型問題避免把錯誤帶到CI階段。配合編輯器的實時提示基本上能做到“寫的時候就知道對不對”。