GraphQL vs REST：2026 年 API 技术选型实战指南

前言

每次启动新项目，API 技术选型都是团队必经的争论。REST 稳如老狗，GraphQL 灵活花哨，到底该选哪个？

本文不站队，纯从实战角度帮你理清两者的适用场景。

REST 的优势依然稳固

REST 发展了 20 多年，生态成熟到令人发指：

• 缓存天然友好：HTTP 缓存、CDN、浏览器缓存直接生效
• 调试简单：curl 一行搞定，Postman 随便测
• 团队学习成本低：几乎所有后端开发都写过 REST
• 中间件丰富：限流、鉴权、日志等基础设施开箱即用

# REST 就是这么简单直接
curl https://api.example.com/users/42

GraphQL 真正解决了什么问题

GraphQL 不是来替代 REST 的，它解决的是 数据获取效率 问题：

1. Over-fetching（过度获取）

REST 返回整个资源对象，客户端可能只需要 3 个字段，却拿回来 30 个。移动端网络环境下，这种浪费很痛。

2. Under-fetching（获取不足）

一个页面需要用户信息 + 订单列表 + 推荐商品，REST 要发 3 个请求。GraphQL 一个 query 搞定：

query {
  user(id: 42) {
    name
    orders(last: 5) {
      id
      total
    }
    recommendations(limit: 3) {
      title
      price
    }
  }
}

3. 前端迭代速度

前端改个字段不用等后端发版。这在快速迭代的产品团队里是实打实的效率提升。

2026 年的新变量

tRPC 的崛起

如果前后端都是 TypeScript，tRPC 可能比 GraphQL 更合适。端到端类型安全，零 schema 定义，调用体验像本地函数：

// 服务端
const appRouter = router({
  getUser: publicProcedure
    .input(z.object({ id: z.number() }))
    .query(({ input }) => db.user.findById(input.id)),
});

// 客户端 - 完整类型推断
const user = await trpc.getUser.query({ id: 42 });

GraphQL Federation 成熟了

Apollo Federation v2 让微服务架构下的 GraphQL 不再是噩梦。每个服务管自己的 subgraph，gateway 自动合并。大厂在用，小团队也能上。

REST 的反击：OpenAPI 4.0

OpenAPI 4.0 带来了更好的类型系统和代码生成能力，配合 Orval 等工具，REST 的开发体验大幅提升。

选型决策树

场景	推荐	原因
简单 CRUD 后台	REST	简单够用
移动端 + 复杂数据关系	GraphQL	减少请求，节省流量
全栈 TypeScript	tRPC	开发体验最佳
微服务 + 多端消费	GraphQL Federation	统一数据层
公开 API / 第三方集成	REST	通用性最强
实时数据推送	GraphQL Subscriptions	内置支持

我的建议

别为了用 GraphQL 而用 GraphQL。如果你的 REST API 工作得很好，用户没有抱怨慢，前端没有抱怨字段不够，那就别换。

但如果你遇到了这些信号：

• 前端频繁要求新接口或改字段
• 移动端性能因网络请求过多受影响
• 多个客户端消费同一套数据但需求差异大

那是时候认真考虑 GraphQL 了。

技术选型没有银弹，只有 最适合当前团队和业务 的选择。