传统 REST 的痛点是“接口和页面需求绑死”：一个页面多个接口、一个接口返回大量用不到字段。GraphQL 用强类型 Schema 描述数据能力，客户端按需查询。
但它也有成本：服务端复杂度、缓存难度、N+1 问题，都需要专门治理。
适用判断：多端取数需求差异大、字段裁剪诉求强的场景收益最高；简单 CRUD 用 REST 更省。
掌握这些就能上手。
类型、字段、查询入口定义。
声明式查询，按需取数。
写入操作与返回结果。
字段解析与数据获取。
DataLoader 解决 N+1。
Apollo 等缓存方案。
从选型到稳定运行。
确认多端取数差异大、字段裁剪需求强，才值得引入。
以业务实体为基础设计类型与查询，作为前后端契约。
实现字段解析，用 DataLoader 合并批量查询，治理 N+1。
接入缓存、查询分析、性能监控，保障稳定。
两种 API 范式对比。
| 维度 | GraphQL | REST |
|---|---|---|
| 取数灵活性 | 高（按需） | 低（接口定死） |
| 接口数量 | 单一端点 | 按资源多接口 |
| 缓存复杂度 | 高 | 低 |
| 学习成本 | 中高 | 低 |
| 适合场景 | 多端/字段多变 | 常规 CRUD |
用 DataLoader 合并同类查询、批量加载关联数据，避免每个字段触发一次数据库查询。
持久化查询 + 结果缓存 + 客户端缓存（Apollo）组合，缓存策略比 REST 复杂，需专门设计。
在 Resolver 层做权限校验，或基于 Schema 的指令做字段级鉴权。
简单 CRUD、团队没有精力治理复杂度、性能要求极致的场景，用 REST 更合适。
