告别 REST 的过度请求——客户端精确声明所需数据，单端点、强类型、实时订阅
REST API 存在两个经典问题：过度获取（Over-fetching）——拿到比需要更多的字段；欠获取（Under-fetching）——需要发送多个请求才能拿齐所需数据。在移动端，这两个问题尤其严重，因为带宽有限而 REST 端点往往是为桌面 Web 设计的。
2012 年，Facebook 的移动团队在开发 News Feed 时遇到了这个问题，于是内部开发了 GraphQL。2015 年开源后，GitHub、Shopify、Twitter、Airbnb 等公司相继采用，GraphQL 逐渐成为现代 API 设计的重要选项。
GraphQL 的核心思想是：客户端告诉服务器它需要什么，服务器精确返回这些数据，不多也不少。这依赖于强类型的 Schema 系统和声明式查询语言。
GraphQL 重新定义了客户端与服务器的数据交互方式
客户端精确声明需要哪些字段，服务器只返回这些字段，消除过度获取。
强类型 Schema 是 API 的契约，自动生成文档，前后端类型安全。
Subscription 通过 WebSocket 实现服务端推送，适合实时通知、聊天等场景。
客户端可以查询 Schema 本身的结构，支持动态探索 API 能力。
批处理 + 缓存机制，自动解决 N+1 查询问题，大幅提升后端性能。
Apollo Federation 将多个 GraphQL 服务合并为统一的超图，支持微服务架构。
从零掌握 GraphQL，构建生产级 API
REST 的痛点，Facebook 开发背景，GraphQL vs REST vs gRPC，安装 Apollo Server，Playground。
type/scalar/enum/input/union/interface，内置标量，自定义标量，Non-null，schema 设计原则。
字段选择，参数，别名，片段，操作名称，变量，指令 @include/@skip，内省查询。
mutation 操作，input 类型，乐观 UI，错误处理模式，事务操作，文件上传。
WebSocket 协议，PubSub 实现，Redis PubSub，withFilter 过滤，实时聊天示例。
Resolver 签名，context 传递，DataLoader 批处理原理，解决 N+1，Resolver 链。
JWT 验证，context 注入，graphql-shield，字段级权限，RBAC，AuthenticationError。
Offset 分页局限，Relay Cursor 规范，edges/node/cursor，pageInfo，无限滚动实现。
DataLoader 批处理，查询复杂度限制，持久化查询，@cacheControl，CDN 缓存。
Apollo Client，useQuery/useMutation/useSubscription，GraphQL Codegen，类型安全查询。