第十四章：适合什么场景，不适合什么场景 —— 总台别乱建

适合 GraphQL 的场景

1. 多端并存
   Web、移动端、运营后台、合作方客户端，对同一批业务对象要不同视图

2. 关系复杂
   用户、订单、商品、评论、库存、推荐互相勾连，页面经常跨多个对象拿数据

3. 前端迭代快
   前端不想每改一个页面就等后端新开接口

4. 聚合层/BFF 场景
   背后有多个 REST、RPC、数据库、微服务，需要一个统一总台做聚合

5. 需要强类型协作
   团队希望把“能问什么、能改什么”写成清晰合同

不太适合 GraphQL 的场景

1. 接口非常简单
   就几个固定 CRUD，且客户端需求稳定

2. 强依赖传统 HTTP 语义
   大量基于 URL、动词、状态码、代理层规则做治理

3. 以文件上传/下载、大流式传输为主
   这些通常不是 GraphQL 最舒服的主战场

4. 团队没有 Schema 治理能力
   GraphQL 不是“省设计”，反而更考验命名、边界、字段治理

5. 公共开放平台且接入方极多
   如果查询复杂度控制、权限控制、限流策略做不好，总台会被问爆

最务实的判断标准：

如果你的问题是“接口太多、页面总缺字段、跨服务拼数据很痛苦”
GraphQL 往往值得上

如果你的问题只是“想试个新技术”
那通常不是上 GraphQL 的理由