GraphQL vs REST：我们为什么又切回了 REST
GraphQL vs REST: Why We Switched Back to REST
| Alex | 2026-08-31T11:23:59
去年把几个核心 API 从 REST 切换到了 GraphQL，用了半年之后又切回来了。这篇文章聊聊具体原因。
Migrated core APIs from REST to GraphQL last year, then switched back after six months. Here's why.
去年团队里有人提议用 GraphQL 替代 REST，说 GraphQL 灵活、减少请求次数、类型安全。我们试了半年之后又切回了 REST，不是说 GraphQL 不好，而是不适合我们的场景。 当初为什么选 GraphQL 主要有两个痛点： 前端经常抱怨 REST 接口返回的数据太多或太少，要么冗余字段太多浪费带宽，要么需要的数据要调好几个接口拼 后端给不同页面写不同的 DTO 太烦了 GraphQL 的"要什么取什么"确实完美解决了这两个问题。 半年后遇到的问题 1. N+1 查询问题 这是最痛的。GraphQL 的 resolver 嵌套调用，不注意就会产生大量数据库查询。虽然有 DataLoader 可以批量化，但是每个 resolver 都要手动处理，心智负担很大。 2. 缓存困难 REST 的 HTTP 缓存天然支持（GET 请求 + URL 做缓存 key），GraphQL 因为所有请求都是 POST 到同一个端点，HTTP 缓存基本废了。要做缓存只能在应用层处理，复杂度高很多。 3. 监控和限流困难 REST 的每个端点都有独立的 URL，监控延迟、设置限流都很直观。GraphQL 一个端点承载所有查询，你很难区分"查用户列表"和"查用户详情+订单+地址"的性能表现。 4. 学习成本 前端同学需要学 GraphQL 的查询语法，后端需要学 Schema 定义和 Resolver 编写。团队里一半人之前都没接触过，上手成本不低。 切回 REST 之后怎么解决原来的痛点 数据冗余问题：用 JSON 的 fields 参数让前端指定需要的字段，后端 SELECT 时只查这些字段 多次请求问题：针对特定页面提供聚合接口（BFF 层） 什么场景适合 GraphQL 如果你的场景符合以下特点，GraphQL 可能是更好的选择： 数据模型复杂且关联性强 有多端（Web、App、小程序）且数据需求差异大 团队有 GraphQL 经验 主要是读操作，写操作不多
Tried GraphQL for six months, then switched back to REST. Not because GraphQL is bad - it just didn't fit our use case. Problems We Hit N+1 query problem (DataLoader helps but adds mental overhead) HTTP caching is effectively broken (all POST to one endpoint) Monitoring and rate limiting are much harder with a single endpoint Significant learning curve for the team How We Solved the Original Pain Points with REST Field selection via query params, and BFF aggregation endpoints for specific pages. GraphQL fits best when: complex data models, multiple clients with different needs, team has experience, read-heavy workloads.