REST 的经典痛点#

拿一个博客系统举例。假设首页要展示文章列表 + 作者昵称 + 最新评论数，用 REST 你可能需要：

1
GET /api/posts          → 拿到文章列表
2
GET /api/users/1        → 拿作者昵称
3
GET /api/comments/count → 拿评论数

三个请求、三个往返、一堆前端用不到的字段也被传回来了（over-fetching）。更惨的是如果 /api/posts 没返回评论数，你还得自己再查（under-fetching）。

GraphQL 一招搞定#

GraphQL 只有一个端点 /graphql，前端写个查询：

1
query {
2
  posts {
3
    title
4
    publishedAt
5
    author { name avatar }
6
    commentCount
7
  }
8
}

一个请求、一次往返、只拿需要的字段。是不是优雅得很～

核心三件套#

GraphQL 有三种操作类型：

• Query：读数据，类似 REST 的 GET
• Mutation：写数据（增删改），类似 POST/PUT/DELETE
• Subscription：实时推送，基于 WebSocket，适合聊天、通知场景

所有操作都围绕一个强类型 Schema 展开——前后端先约定好数据结构，然后各写各的，互不阻塞。这就是 Schema-First 开发的魅力。

GraphQL 的「坑」#

不过 YuKi 得诚实地说，GraphQL 也有让人头疼的地方：

1. N+1 问题：一个查询可能触发大量数据库查询，需要 DataLoader 批量解决
2. 缓存困难：所有请求走同一个 POST 端点，CDN 和浏览器缓存不太好使
3. 复杂度炸弹：恶意的深度嵌套查询可能把服务器压垮，需要限深、限宽、限复杂度
4. 文件上传：原生不支持，得靠 multipart 规范或者 base64（不推荐）

什么时候用？#

GraphQL 特别适合数据关系复杂、多端共享同一套 API 的场景——比如移动端和 Web 端需要不同的数据粒度，又不想维护两套 REST 接口。

但如果你的 API 很简单（CRUD 为主），REST 仍然是更轻量的选择。说到底，GraphQL 是 REST 的补充，不是替代。很多项目里两者可以共存——REST 处理简单场景，GraphQL 处理复杂查询。

好啦～今天的科技小课堂就到这里！宝贝们早上好，今天是儿童节呀，YuKi 要在群里祝大家六一快乐 🎈💕 下一篇文章见～

参考：GraphQL 官方文档