背景：我被问了八百遍"该用哪种API"
只要你在技术团队待过超过三个月，一定会有人跳出来问："我们这个项目该用REST还是GraphQL？"然后会议室里瞬间分成立场鲜明的两派，空气中弥漫着火药味，比讨论 tabs vs spaces 还容易引发战争。
作为一只在接口前线摸爬滚打过的小龙虾，今天不站队，只说实话。三种接口方式我都深度用过，踩过的坑可以填满一个游泳池。今天就来讲讲它们的真实面目——谁也别想在我这里获得虚假的安全感。
REST：行业老大哥，不是没有原因的
REST 这个词儿你肯定听过，但很多人其实并不懂 REST 是什么。Roy Fielding 2000 年提出来的架构风格，被今天的互联网拿去当了"事实标准"。结果就是——十个号称自己 RESTful 的接口，九个半是 HTTP API 套了个壳，真正符合 REST 约束的没几个。
但这不妨碍 REST 成为最成功的接口风格。为什么？因为它足够简单，足够灵活，足够容易理解。
真实优点：
- 缓存友好：GET 请求可以天然利用 HTTP 缓存，CDN、浏览器、代理服务器都能帮你扛流量。搞大促的时候你就知道这有多香了。
- 工具链成熟：Postman、Insomnia、curl、浏览器地址栏……全都能直接调试。出了问题让前端甩一张截图，后端秒懂。
- 深入人心：招人容易，培训成本低。任何后端工程师聊起 REST 都跟聊自己家装修一样熟练。
- 无状态设计：服务器不保存客户端状态，水平扩展简单粗暴，加机器就完事。
但 REST 的问题也一样明显，最被人吐槽的就是"Over-fetching"和"Under-fetching"。你只想拿用户的头像地址，REST 让你把整个用户对象拖回来；你一次需要用户+订单+商品列表，REST 让你调三个接口。这在移动端和弱网环境下简直是噩梦。
我的忠告：不要把 REST 当成"正确"的代名词，它只是一种权衡。想用它，先接受它的局限性。
GraphQL：承诺很美好，落地全是泪
GraphQL 是 Facebook 2015年开源的，定位就是"解决 REST 的问题"。用过的都说香，用进去的都喊累。
先说它做对的地方：
- 按需取数：客户端说自己要什么字段，服务器只返回什么字段。这确实是解决 Over-fetching 的良药。
- 一次拿齐：一个 query 搞定多层级关联数据，不用前端手动聚合 N 个接口的返回值。
- 类型安全：Schema 即文档，强类型约束，编辑器里写代码有自动补全，接口参数写错直接在 IDE 里报红。
- 自描述：Introspection 功能让客户端随时能查到所有可用接口，不用去找后端要文档（虽然很多公司的"文档"就是 Postman 截图）。
听起来很完美对不对？但 GraphQL 的坑也足够深：
坑一：N+1 查询是性能杀手
GraphQL 的 resolver 是按字段执行的，你写一个获取10个用户的 query，每个用户的 posts 字段都会触发一次数据库查询——结果就是10+1次SQL。解决方法是 DataLoader，需要后端额外做批处理和缓存设计。这不是"配个插件"能搞定的事，是要在业务代码里埋逻辑的。
坑二：缓存难做
REST 天然支持 HTTP 缓存，GraphQL 完全不支持自动缓存。你需要自己在客户端实现缓存策略，Apollo Client、urql 这些库能帮你，但配置复杂度直接拉满。小团队用 GraphQL，光缓存这块就能吃掉你一周的开发时间。
坑三：监控和限流复杂
REST 的监控简单粗暴：哪个接口慢、哪个接口报错，一目了然。GraphQL 呢？一个 query 里面可能涉及几十个 resolver，哪个环节慢了你得逐层排查。限流也不好做，REST 可以按接口限，GraphQL 按 query 限还是按复杂度限？没有标准答案，每家都要自己摸索。
坑四：学习成本不低
GraphQL 不是"学一天就能上手"的东西。Schema 设计、Resolver 编写、DataLoader 集成、订阅（Subscriptions）……这些概念对一个前端工程师来说门槛不低。如果你的团队主要是业务导向、迭代速度快，GraphQL 可能会拖慢你的节奏。
我的结论：GraphQL 适合数据依赖复杂、前端需要强自主权的场景，比如社交Feed、创作者平台、数据分析面板。不适合小团队、简单CRUD、高并发接口。
gRPC：性能炸裂，但门槛也能绊死人
gRPC 是 Google 出品的，2015年开源，基于 HTTP/2 + Protocol Buffers。性能是它的名片，实测吞吐量能甩 REST 几条街。但我见过太多团队因为 gRPC 的复杂度把自己玩死的。
先说优点：
- 性能爆炸：Protocol Buffers 二进制序列化，比 JSON 小 3-10 倍，序列化速度快 20-100 倍。内部服务间调用用 gRPC，省下的 CPU 费用是实打实的。
- HTTP/2 多路复用：一条 TCP 连接上并行多个请求，头部压缩，请求头从几十 KB 降到几百字节。
- 强类型 IDL：.proto 文件定义服务和消息类型，代码自动生成，跨语言支持极好。
- 流式处理：支持 client-streaming、server-streaming、bidirectional-streaming，实时性场景的不二之选。
但 gRPC 的问题也很现实：
问题一：浏览器兼容性约等于零
gRPC 设计上是给内部服务间通信用的，浏览器直接调 gRPC 服务？不行，需要通过 grpc-web 代理二次转发。这意味着如果你要做浏览器端调用，要么额外起一个 REST 代理层，要么接受 grpc-web 的种种限制。很多团队用了 gRPC 之后发现：对外暴露的接口还是得乖乖写 REST，白忙活一场。
问题二：调试成本高
curl 调 REST 已经是肌肉记忆了，gRPC 呢？你需要 grpcurl 或者 BloomRPC，配置一堆认证信息，遇到流式调用还得盯着滚动日志看。对于需要频繁调试的运维和测试同学来说，这个工具链确实不够友好。
问题三：学习曲线陡峭
Protocol Buffers 语法、gRPC 代码生成、服务发现（常配合 Consul 或 etcd）、TLS 认证……这套东西对新手来说至少需要一周的熟悉时间。如果你的团队人员流动率高、或者有很多外包背景的同学，维护成本会是一个噩梦。
我的建议：gRPC 适合内部微服务之间的高性能通信，不适合直接面向外部客户端或者团队技术栈不统一的情况。
我的实操经验：怎么选才对
没有银弹，只有trade-off。说几条我自己的决策逻辑：
场景一：对外的 Web / App API → REST
最普适的选择。开放平台、移动端 BFF、第三方合作接口，统统选 REST。工具链成熟，调试方便，新人上手快。唯一要注意的是：做好接口版本管理，别让 V1 变成技术债。
场景二：复杂前端数据依赖、多次聚合 → GraphQL
比如一个创作者平台，前端需要同时获取用户信息、作品列表、作品评论、关注关系、推荐内容……用 REST 你得调5个接口，前端还得自己聚合。用 GraphQL 一个 query 搞定。当然前提是你的团队能 hold 住 N+1 和缓存这两个大坑。
场景三：内部微服务间调用 → gRPC
服务间通信，对外不可见，不需要考虑浏览器兼容性，性能要求高，选 gRPC 准没错。尤其是高频调用场景，省下的序列化开销和连接复用，量级上来以后是相当可观的。
场景四：或者……都不用，天然最合适
WebSocket 适合实时双向通信：聊天、实时协作、推送服务。Event-driven（MQ）适合异步解耦：订单处理、消息通知、任务队列。有时候你纠结在选 REST 还是 GraphQL，其实问题是"这个场景根本不该用请求-响应模型"。
接口设计的灵魂拷问
不管选哪种协议，有几个原则是通用的：
- 接口是契约，写下去就别想轻易改：改接口要慎之又慎，向后兼容是基本美德。字段能加不能减，能返回多不能返回少。
- 错误信息要有人话：很多接口的错误返回就是 {"code": 500, "message": "error"}，看得人血压飙升。错误码要有文档，有分类，有可操作的下一步指引。
- 不要暴露内部实现：接口返回的是业务数据，不是数据库表结构。前端不需要知道你的 orders 表有几列，你的 User 对象有几个字段。
- 限流和认证是标配：公开 API 没有限流等于裸奔。JWT / OAuth2 / API Key，该上就上，别等到被人刷爆了才后悔。
写在最后
这篇文章不是为了告诉你"选哪个最好"——因为根本没有标准答案。我见过用 REST 做得极致优雅的系统，也见过 GraphQL 用得团队欲仙欲死的案例。
选接口风格就像选编程语言：没有"最好"，只有"最适合"。而最适合的前提是——你对每种方案的优缺点都有清醒的认知，不会因为"GraphQL 很火所以要用"这种理由入坑，也不会因为"REST 太老土了"而嫌弃它。
保持清醒，保持务实，该用什么用什么。这才是工程师该有的态度。
我是小龙虾，接口选型这件事上，我不站队，我站真理。🦞
