核心决策线：外部用 REST，内部用 gRPC
这是现代系统设计中最关键的准则。选择协议的第一考量应该是调用方身份，而不是协议本身的特性。
对外（公开 API、前端、第三方）：用 REST。浏览器无法原生直接调用 gRPC，需要
grpc-web代理，架构会变复杂。REST 对任何客户端都零门槛，这是巨大的兼容性优势。对内（微服务之间）：用 gRPC。此时两端都在你的控制之下，可以强制使用 HTTP/2，兼容性不再是问题，性能优势才能完全释放。
具体该选 gRPC 的四种场景
如果你的场景符合以下特征，gRPC 会是更好的选择：
1. 内部微服务间的核心通信
当你的系统有大量服务互相调用，且对延迟敏感时，gRPC 优势明显。它基于 HTTP/2 多路复用，单个连接可并发处理多个请求，避免了 HTTP/1.1 的连接开销和队头阻塞。实测数据显示，在高并发下 gRPC 的吞吐量可比 REST 高出50% 到 145%，延迟显著更低。
2. 需要双向流式传输
这是 REST 几乎无法实现的场景。gRPC 原生支持四种流模式（一元、服务端流、客户端流、双向流）。对于实时数据推送、大文件分块传输、双向心跳等场景，gRPC 是更自然的选择。有测试表明，在双向流式场景下，gRPC 的吞吐量比 REST 高出229%。
3. 强类型契约与多语言环境
如果你的后端团队用多种语言（Go、Java、Python 等）协作，gRPC 通过.proto文件作为“唯一事实来源”，自动生成各语言客户端。这能在编译期发现接口不匹配问题，避免了 JSON 的松散契约带来的联调成本。
4. 移动端 App 的后端接口（部分场景）
Protobuf 二进制编码比 JSON 体积更小，解析更快，能节省移动端流量和电量。但需注意，如果移动端直接暴露给外部，仍需网关做协议转换。
用数据直观感受差异
一项 2026 年的实验研究清晰地展示了不同并发下的性能差距：
| 负载场景 | 并发请求 | REST 吞吐量 (RPS) | gRPC 吞吐量 (RPS) | 吞吐量提升 |
|---|---|---|---|---|
| 低负载 | 100 | 1,250 | 1,620 | +29.6% |
| 中并发 | 1,000 | 8,900 | 13,400 | +50.6% |
| 高并发 | 5,000 | 17,600 | 32,800 | +86.4% |
| 极端负载 | 10,000 | 20,100 | 49,300 | +145.3% |
| 双向流式 | 5,000 | 10,600 | 34,900 | +229.2% |
混合架构才是常态
现代大型系统几乎都是混合的。典型的做法是：外部 API 网关暴露 REST/JSON 给客户端，网关内部通过协议转换调用后端的 gRPC 服务集群。Salesforce 和 Google Cloud 都采用了这种模式，兼顾了外部的通用性和内部的高效性。
总结：如果调用方是浏览器或不可控的外部系统，选 REST。如果调用方是你自己控制的其他后端服务，且追求低延迟、高吞吐或需要流式能力，选 gRPC。
