gRPC 和 REST 什么时候用哪个？
更新时间：2026-09-18。问题驱动短答页。这不是谁取代谁，而是按调用方、网络环境、性能要求选。
一句话回答
内部服务之间、多语言、追求高性能或需要流式调用 → gRPC；对外开放 API、浏览器/第三方直接调用、要便于人肉调试和利用 HTTP 缓存 → REST/JSON。大量公司是「内部 gRPC + 边界 REST」，靠网关互转。
核心差异
| 维度 | gRPC | REST/JSON |
|---|---|---|
| 协议 | HTTP/2（多路复用、头部压缩） | 多用 HTTP/1.1（也可 HTTP/2） |
| 序列化 | Protobuf 二进制，体积小、解析快 | JSON 文本，体积大、可读性好 |
| 契约 | .proto 强类型、自动生成多语言 SDK | OpenAPI/Swagger（可选） |
| 调用模式 | 一元 + 服务端/客户端/双向流 | 主要请求-响应，流式需 SSE/WebSocket |
| 浏览器 | 不能直接调（需 gRPC-Web + 代理） | 原生支持 |
| 调试 | 需工具（grpcurl、反射），二进制不可读 | curl/浏览器直接看 |
| HTTP 缓存 | 基本用不上 | GET 天然可缓存 |
| 流式/长连接 | 内建四种流，强 | 要另选 SSE/WebSocket |
怎么选
选 gRPC 的信号：
- 微服务内部高频互调，在意延迟和带宽；
- 团队多语言（Java/Go/Python/Node），想用
.proto做单一事实来源、自动出 SDK； - 需要双向流（实时推送、长连接数据通道），见 gRPC 四种流模式与双向流。
选 REST 的信号：
- API 直接给浏览器、移动端或外部第三方，要简单、通用、好调试；
- 依赖 GET 缓存、CDN、标准 HTTP 状态码；
- 团队小、迭代快，不想维护 proto 与代码生成链路。
常见组合：边界 REST，内部 gRPC
坑
- 浏览器直接调 gRPC：标准 gRPC 依赖 HTTP/2 trailer，浏览器 fetch 不支持，必须 gRPC-Web + Envoy/网关代理，别漏了这层。
- proto 演进破坏兼容：删字段、改字段编号会让新旧版本解析错乱，要保留字段号、用
reserved。 - 用 gRPC 就忽略超时/鉴权：这些靠 metadata 和拦截器实现，见 gRPC 拦截器：鉴权、日志与指标。
- 内部长连接不调 keepalive：NAT/负载均衡可能静默断连，见 gRPC 性能：keepalive 与连接复用。
基础概念见 gRPC 与 Protobuf 与 REST API 设计规范。
总结
gRPC 基于 HTTP/2 多路复用和 Protobuf 二进制，体积小、性能高、契约强且内建四种流式调用，但浏览器不能直连、调试不直观、用不上 HTTP 缓存，适合内部多语言微服务与实时流；REST/JSON 通用、可读、curl 即可调、天然支持缓存和第三方/浏览器直连，适合开放 API 与边界场景；最常见落地是「外部 REST + 内部 gRPC」由 API 网关做协议与鉴权转换，选 gRPC 时务必补上 gRPC-Web、proto 兼容性规范和 keepalive/拦截器这些配套。