GraphQL vs tRPC：2026年API设计方案怎么选？

引言

选 API 方案一直是后端架构中绕不开的话题。REST 已经是老朋友了，GraphQL 红了好几年，而 tRPC 作为后起之秀正在快速抢占市场。本文从实际项目角度对比这两种方案。

GraphQL 的优势与痛点

优势

• 灵活查询：客户端按需获取数据，减少 over-fetching
• 强类型 Schema：自带类型系统，文档即代码
• 生态成熟：Apollo、Relay、Hasura 等工具链完善

痛点

• N+1 查询问题：不做 DataLoader 优化很容易出现性能灾难
• 缓存复杂：HTTP 缓存失效，需要 Apollo Cache 等额外方案
• 学习成本：Schema 设计、Resolver 编写有一定门槛

tRPC 的优势与痛点

优势

• 端到端类型安全：前后端共享类型，零代码生成
• 极简：没有 Schema、没有代码生成步骤
• 和 TypeScript 深度绑定：用 TS 的团队几乎零学习成本

痛点

• 强绑定 TypeScript：非 TS 项目无法使用
• 跨语言支持差：没有 Schema 就没法给其他语言的客户端用
• 不适合公开 API：更适合全栈单体应用

怎么选？

场景	推荐
全栈 TS 应用（Next.js）	tRPC
多客户端（Web + App + 第三方）	GraphQL
微服务间通信	gRPC（都别选）
快速原型	tRPC
需要公开 API	GraphQL 或 REST

实战建议

1. 小团队全栈项目：直接上 tRPC + Next.js，开发速度飞快
2. 中大型项目：GraphQL + Codegen 依然是最稳妥的选择
3. 混合方案：内部用 tRPC，对外暴露 REST/GraphQL 网关

总结

没有银弹。tRPC 在全栈 TypeScript 场景下体验极佳，但 GraphQL 在跨平台、跨语言场景下仍然不可替代。选型时先看团队技术栈和业务需求，别追热度。