tRPC：让前后端共享类型，告别 REST API 文档
tRPC Share Types Between Frontend and Backend No More REST API Docs
| iDev Team | 2026-07-21T09:30:00
tRPC 让 TypeScript 全栈项目的前后端共享类型定义，调用后端函数就像调用本地函数一样，自动补全、类型检查、零 API 文档。
tRPC lets TypeScript full-stack projects share type definitions between frontend and backend. Calling backend functions feels like calling local functions with auto-complete and type checking.
REST API 的痛点传统 REST API 开发中，前后端之间存在一个"信任鸿沟"：后端定义了接口，前端需要按照文档调用。但文档经常过时、字段名拼错不会报错、参数类型不匹配要到运行时才发现。tRPC 如何解决tRPC 在 TypeScript 全栈项目中消除了这个鸿沟。后端定义一个函数（procedure），前端直接调用这个函数，TypeScript 编译器保证参数和返回值的类型完全匹配。核心优势端到端类型安全：后端改了返回类型，前端立刻报红色错误零 API 文档：类型就是文档，IDE 自动补全就是最好的文档自动补全：前端调用后端函数时，IDE 能提示所有可用的参数和返回字段轻量：核心库只有 2KB适用条件tRPC 需要前后端都用 TypeScript，且在同一个 monorepo 中（或通过 npm 包共享类型）。如果你的后端是 Java/Go/Python，或者前后端团队分离，tRPC 不适合。与 REST/GraphQL 对比维度RESTGraphQLtRPC类型安全无（需 Swagger/OpenAPI）Schema 级别端到端代码生成需要需要不需要学习曲线低中低适用语言任意任意仅 TypeScriptiDev 的观点对于 TypeScript 全栈项目（如 Next.js + Node.js），tRPC 是开发效率最高的方案。但对于异构技术栈（如 Vue + Java），REST 仍然是最通用的选择。
The REST API Pain PointTraditional REST development has a trust gap between frontend and backend: outdated docs, typos in field names, and type mismatches only caught at runtime.tRPC vs REST vs GraphQLDimensionRESTGraphQLtRPCType SafetyNone (needs Swagger)Schema-levelEnd-to-endCode GenerationRequiredRequiredNot neededLanguage SupportAnyAnyTypeScript only