RPC与gRPC核心原理：HTTP/2、Protobuf编码及线上超时排查实践-代码聚汇网

RPC与gRPC核心原理：HTTP/2、Protobuf编码及线上超时排查实践

程铭夜·2026-08-31·阅读 24 GEO检测（免费）

RPCgRPCProtobuf

|难度：普通|阅读约 24 分钟

上个月排查一个线上告警，服务调用方一直报 cannot finish rpc call in 30 seconds，我一开始以为是网络抖动，后来顺着链路查下去，发现是服务端 GC 长停顿把一次正常调用拖垮了。排查的过程让我意识到，很多人（包括我自己）天天在用 RPC、gRPC、Protobuf，但真的遇到问题时，对这套分布式通信核心栈的理解还是不够系统。这篇内容我就把 RPC 的本质、gRPC 为什么选 HTTP/2 + Protobuf、编码原理、框架选型，以及几个真实环境里踩过的坑一次讲清楚。适合刚接触微服务、或者已经被 RPC 报错折磨过的后端同学，也适合想搞清楚“HTTP 和 RPC 到底啥关系”的读者。

1. 从超时报错说起：RPC 到底解决的是什么问题

先回到那个 30 秒超时报错。cannot finish rpc call in 30 seconds 这种消息，说明客户端设置了一个 30 秒的超时窗口，但调用没有在这个窗口内拿到结果。这背后其实引出了一个很本质的问题：本地调用和远程调用之间，隔的不是一个函数签名的距离，而是一整张网络。

1.1 本地调用和远程调用之间隔着一整张网

写单机程序时，orderService.getOrder(id) 就是一次普通的函数调用，压栈、传参、返回，毫秒级完成，没有网络参与。但一旦拆成微服务，这个调用就变成了：

客户端要把 getOrder 这个意图“告诉”另一个进程；
参数要序列化成字节流；
字节流要穿过 TCP 连接，可能经历重传、拥塞、乱序；
服务端要解析出是哪个方法、哪些参数；
执行完还要把结果序列化传回来。

这一串流程里，任何一环出问题，调用方看到的就是“报错”或“超时”。RPC（Remote Procedure Call，远程过程调用）的价值，就是把这一堆网络细节藏起来，让程序员感觉“我就是在调一个本地方法”。

1.2 RPC 不是“HTTP 之外的某种东西”，而是一种调用方式

很多人会把 RPC 和 HTTP 对立起来，觉得“HTTP 是 REST，RPC 是二进制传输”，这个理解不太准确。

RPC 是一种设计思想：远程调用要像本地调用一样简单。它不限定底层必须用什么协议——gRPC 是基于 HTTP/2 的 RPC，Dubbo 用自定义 TCP 协议，Java RMI 用 JRMP 协议，它们本质上都是 RPC 思想的实现。

HTTP 是一种应用层协议，它既可以承载 RESTful 接口，也可以承载 RPC 风格的消息。所以更合适的说法是：HTTP 是底层的“传输管道”之一，RPC 是管道的“封装方式”。把这两个概念分开，再看各种框架就清晰多了。

1.3 那 30 秒超时到底是怎么来的

我那次排查的链路是这样的：客户端配了 30 秒超时，服务端日志显示请求确实收到了，但处理耗时超过 25 秒。继续往下看，服务端那个实例的 GC 日志里出现了多次秒级停顿，数据库连接池也打满了，大量线程在等连接。

问题不在 RPC 框架本身，而在于：

服务端依赖的数据库连接池太小，高峰期排队；
GC 停顿让线程阻塞；
客户端把超时设成了统一的 30 秒，没有按接口区分。

这里有个经验：RPC 超时配置不能“一个值走天下”。读接口、写接口、批量查询接口的耗时特征完全不同，统一配置要么导致频繁误报，要么导致故障长时间无感知。建议按接口的 p99 延迟来设定超时，比如 p99 是 200ms，超时可以设为 1 秒左右；同样，超时报警也要区分“超时但被重试成功”和“超时且失败”两种情况。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 拆开一次 RPC 调用：从客户端到服务端的完整链路

理解 RPC 最好的方式，是亲手拆一次调用。不管用 gRPC 还是 Dubbo，一条完整的 RPC 调用链路都包含几个固定环节。

2.1 一次调用的 5 个环节

还是拿 orderService.getOrder(id) 举例，走完一次 RPC 调用，实际发生了这些事：

客户端调用本地代理（Stub）：调用方调用的不是一个真正的远程对象，而是一个本地生成的代理类。代理类负责伪装成“本地服务”，把方法名、参数值打包。
序列化：把方法名（或者接口 ID）和参数值转成二进制。gRPC 用 Protobuf，Dubbo 默认用 Hessian2，Java RMI 用 Java 原生序列化。
网络传输：序列化后的字节流被写入传输层。gRPC 走 HTTP/2 流，Dubbo 走自定义 TCP 协议。
服务端反序列化：服务端接收字节流，还原出方法名和参数，找到对应的服务实现。
执行并返回：业务逻辑执行完，结果再走一遍序列化、传输、反序列化，回到客户端。

其中第 2 步和第 4 步直接决定 RPC 的性能上限，因为序列化是最耗 CPU 的环节之一。这也是 Protobuf 能在 gRPC 里站稳脚跟的原因——后面我会单独讲它的编码原理。

2.2 动态代理和 IDL：RPC 的“翻译官”

有了 Stub，客户端代码才能写 service.getOrder(id) 而不是手动拼字节流。这个 Stub 怎么来？两种方式：

动态代理：运行时根据接口定义自动生成代理对象。Java 里就是 Proxy.newProxyInstance 那一套，Dubbo 老版本大量使用这种方式。
代码生成：根据 IDL（Interface Definition Language，接口定义语言）文件在编译期生成客户端和服务端代码。gRPC 用的就是这种方式。

IDL 是 RPC 体系里容易忽略但非常关键的东西。它解决的是“语言无关”的问题：一份 order.proto 定义了接口和数据结构，用 protoc 可以生成 Java、Go、C++、Python 等任意语言的代码。这样 Java 服务就能无缝调用 Go 服务，两边看到的接口定义完全一致。

下面是一个最简单的 Protobuf IDL 例子：

protobuf复制syntax = "proto3";

package order;

service OrderService {
  rpc GetOrder(GetOrderRequest) returns (GetOrderResponse);
}

message GetOrderRequest {
  int64 order_id = 1;
}

message GetOrderResponse {
  int64 order_id = 1;
  string status = 2;
}

用 protoc --java_out 生成代码后，客户端只需要调用 stub.getOrder(request)，服务端只需要实现 GetOrder 方法，剩下的序列化和网络通信全部由生成的代码完成。

2.3 同步、异步和流式：RPC 不是只有“请求一次、响应一次”

很多人以为 RPC 只能是“一来一回”，实际上成熟的 RPC 框架都支持多种调用模式。gRPC 定义了四种：

Unary（一元调用）：客户端发一个请求，服务端回一个响应，最常用。
Server streaming（服务端流式）：客户端发一个请求，服务端多次返回。适合大文件下载、日志推送。
Client streaming（客户端流式）：客户端多次发送，服务端汇总后返回一次。适合上传大量数据后得到一个汇总结果。
Bidirectional streaming（双向流式）：两端同时收发。适合聊天、实时协同。

区分这些模式的意义在于，你不需要用“多次 unary 调用 + 复杂的状态管理”去模拟流式交互。跨服务传输大对象时，服务端流式比一次性返回几十 MB 的响应要稳得多，因为客户端可以边收边处理，内存压力小很多。

3. gRPC 为什么偏偏选中了 HTTP/2 和 Protobuf

gRPC 是 Google 开源的高性能 RPC 框架，它的设计决策里有两个核心：底层用 HTTP/2，序列化用 Protobuf。这俩都不是唯一的选项，但凑在一起产生了很强的化学反应。

3.1 为什么不用 TCP 裸连接自己定协议

有些框架（比如早期 Dubbo）直接在 TCP 上自定义协议，不走 HTTP。这样做的好处是控制力最强——协议简单、头部极短、性能上限高。但坏处也很明显：连接管理、粘包拆包、超时重试、流量控制全都得自己实现，而且每做一个新语言的客户端，都要把协议栈重写一遍。

gRPC 选 HTTP/2 是划算的。HTTP/2 已经不是传统意义上的“HTTP 文本协议”，它把消息拆成二进制帧，在一条 TCP 连接上可以并发跑多个流。gRPC 白拿到了这些能力：

多路复用：一条连接上多个请求并行，不会互相阻塞，解决了 HTTP/1.1 的队头阻塞问题；
头部压缩（HPACK）：每次请求都要带的 method、path、content-type 等元信息可以被压缩，重复的头部只传索引；
流量控制：基于流的窗口控制，避免大数据传输压垮接收方；
TLS 天然集成：HTTP/2 强制加密的要求让安全通道的开箱即用程度很高。

换一个角度说，gRPC 选 HTTP/2 不是为了追求极致性能，而是为了 大幅降低多语言客户端的实现成本。每门语言只要实现 HTTP/2 栈，就能跑 gRPC，这也是 gRPC 成为云原生标配的原因之一。

3.2 HTTP/2 的“流”是 gRPC 流式调用的地基

前面说 gRPC 支持四种调用模式，这个能力直接来自 HTTP/2。HTTP/2 的流可以理解为一个“双向管道”：客户端和服务端都可以往管道里写数据帧，帧的顺序由流 ID 标识，接收方按帧重组出完整消息。

所以 gRPC 的 server streaming 在底层就是：服务端往同一个流里写多个 DATA 帧，客户端持续读取。双向流式则是两端各自维护发送窗口，互不阻塞。如果底层是 HTTP/1.1，一个连接同一时刻只能处理一个请求，流式调用根本无从谈起。

3.3 为什么不是 JSON over HTTP/2

很多人问：HTTP/2 已经很现代了，为什么 gRPC 还要坚持用二进制 Protobuf，不能用 JSON 吗？

技术上是可行的，gRPC 官方也确实支持 JSON 编码（通过 grpc-gateway 或第三方库），但默认还是 Protobuf，原因在于性能和约束：

对比维度	Protobuf	JSON
序列化后大小	小，字段只带 tag 编号	大，重复带字段名和结构符号
编码解码速度	快，二进制直接映射	慢，需要大量的字符串解析
类型约束	强 schema，字段类型编译期检查	弱类型，运行时才发现问题
兼容性	有向后向前兼容机制	需要人工设计字段兼容
调试人读性	差，需要工具转换	好，肉眼直接看

上面这些不是理论差异。一个包含 20 个字段的业务对象，Protobuf 序列化后的体积通常是 JSON 的 1/5 到 1/10。在高 QPS 场景下，省下的不仅仅是带宽，还有 CPU 解析成本。

另外，JSON 作为编码格式还有一个隐患：没有 schema 约束。服务端改了字段类型，客户端可能默默解析出错误数据。而 Protobuf 的 IDL 文件就是双方契约，接口变更必须先改 proto 再生成代码，很多问题在编译期就暴露了。

4. Protobuf 编码原理：一张表看懂 Varint 与 Tag

如果你只是用 gRPC，不深入了解 Protobuf 也能干活。但如果你要排查线上问题、优化消息体积，或者被问“为什么 Proto 字段编号不能乱改”，那编码原理就绕不开了。

4.1 Varint：用最少的字节存一个整数

Protobuf 最核心的编码技术是 Varint。传统场景下，一个 int32 固定占 4 字节，一个 int64 固定占 8 字节。但实际业务里，大部分整数的值都很小（比如订单状态 1、2、3），用 4 字节去存太浪费。

Varint 的思路是：每个字节的最高位作为“是否有后续字节”的标志位（continuation bit），低 7 位存真实数据。遇到一个整数，从低位开始，每 7 位一组，加上一个 leading bit，小端序输出。

以整数 300 为例，二进制是 1 0010 1100，按 7 位分组变成：

010 1100（低位组，后面还有数据，所以 leading bit = 1）
000 0010（高位组，后面没有数据，leading bit = 0）

合起来就是两个字节：1010 1100 和 0000 0010（十六进制 AC 02）。

如果用固定 4 字节存 300，需要 4 字节；用 Varint 只要 2 字节。值越小，省得越多。

但是 Varint 对负数不友好。因为负数在二进制里是符号位为 1 的“大数”，比如 -1 在 int32 里是 0xFFFFFFFF，用 Varint 编码需要 5 个字节。Protobuf 提供了两个补救方案：

sint32 / sint64：使用 ZigZag 编码，把 -1 映射到 1，1 映射到 2，负数也能变成小正数；
fixed32 / fixed64：固定 4/8 字节，适合大整数或者随机性高的值（比如哈希值）。

所以实践建议很明确：可能为负的字段用 sint，随机性大的 ID 用 fixed，普通业务整数用 int。

4.2 Tag：消息的骨架

光有 Varint，接收方还不知道“这串字节对应哪个字段”。这就是 Tag 的作用。

每个 Protobuf 字段在消息里都带有 field_number（字段编号）和 wire_type（线型），组成一个 Tag。以 int64 order_id = 1 为例，字段编号是 1，wire type 是 0，Tag 就是 (field_number << 3) | wire_type = (1 << 3) | 0 = 0x08。

接收方读到 0x08，就知道后面的 Varint 属于字段 1。这就解释了为什么 Proto 文件里字段要手工编号——编号不是摆设，它直接写进了线上传输的每一个 Tag 里。

Protobuf 的 wire type 主要有 5 种：

Wire Type	含义	典型类型
0	Varint	int32, int64, bool, enum
1	64 位固定	fixed64, double
2	长度分隔	string, bytes, 嵌套消息, repeated 字段
5	32 位固定	fixed32, float

string、bytes、嵌套消息这些类型走 wire type 2，也就是先存长度，再存内容。接收方按“Tag + 长度 + 内容”的方式解析，所以消息是自描述的，能够跳过未知字段。

4.3 字段编号为什么不能随便改

理解 Tag 以后，你就会发现一个隐藏的陷阱：字段编号一旦发布出去，就不能再改。

因为线上消息里保存的 Tag 是基于“当时那个字段编号”算出来的。服务端还是老版本，部署了新 proto 文件，把字段 1 从 order_id 改成了 user_id，那老客户端发来的 0x08 就会被新服务端解析成 user_id，数据语义直接错乱。

规范的做法是：

新增字段只用新的编号，绝不复用旧的；

删除字段要用 reserved 关键字占位，防止未来误用：

protobuf复制message Order {
  reserved 2, 15, 9 to 11;
  reserved "old_field";
}

字段编号的可用范围是 1 到 536,870,911，其中 19000 到 19999 是 Protobuf 内部保留段，不要用。

这也是为什么很多团队在 proto review 时特别谨慎：字段编号是一种“一旦发布就永久存在”的接口资产。

5. HTTP 与 RPC 的分界线：选型不是非黑即白

“HTTP 和 RPC 到底怎么选”是社区里的老问题。我的观点是：这不是技术优劣问题，而是服务边界和消费者类型问题。

5.1 HTTP/JSON 在开放 API 场景的优势

如果接口的消费者是你控制之外的第三方——外部合作伙伴、前端页面、移动 App——HTTP/JSON 基本是唯一稳妥的选择。

原因很朴素：

任何语言、任何框架都能发起 HTTP 请求；
JSON 是开发者最容易调试和理解的格式，浏览器的开发者工具、Postman、curl 都能直接处理；
生态工具完善，OpenAPI/Swagger 可以自动化生成文档和客户端；
不依赖特定服务发现或注册中心，一个 URL 就能访问。

把 gRPC 暴露给外部调用方，会让对方被迫学习 Protobuf、安装工具链，大部分外部团队没有这个动力。

5.2 RPC 在内部服务调用的优势

但服务间调用是另一回事。你的上游是另一个团队的 Java/Go 服务，双方都有能力维护 IDL，那 RPC 的优势就很明显：

IDL 让接口契约显式化，接口变更可评审、可审计；
代码生成让客户端和服务端代码保持一致，不会出现“文档说 A，实际返回 B”的偏差；
二进制序列化减少带宽和 CPU 消耗；
gRPC 的流式模型天生适合大数据传输和长连接场景。

尤其在容器化、Kubernetes 环境里，gRPC 的 HTTP/2 长连接反而比 HTTP/1.1 的频繁建连更能节约资源。

5.3 连接不是非此即彼：桥接方案

如果团队内部已经决定用 gRPC，但有个别外部消费者必须走 HTTP/JSON，可以用桥接方案：

grpc-gateway：通过注解方式把 gRPC 服务映射成 RESTful API；
Envoy / APISIX 等网关：在网关层把 gRPC 转成 HTTP/JSON；
ConnectRPC：一个新的 RPC 框架，同时支持 gRPC 协议和 HTTP/JSON 协议，一个服务两种暴露方式。

我自己在项目里的划分标准很简单：对外部开放、需要文档化、消费方不可控的接口，用 REST/JSON；内部服务间高吞吐、强契约、需要流式的调用，用 gRPC。中间再加一层网关做协议转换，两边都能按自己的习惯工作。

5.4 小团队的务实选择

如果是小团队、接口数量不多，我建议先不要急着上 gRPC。先用 HTTP/JSON 把业务跑通，等接口数量多了、跨语言的服务开始增加、或者遇到明显的性能瓶颈时，再逐步引入 gRPC。RPC 框架会带来额外的工具链负担（protoc、代码生成、版本同步），小团队早期不一定消化得了。

6. 框架选型：从 Java RMI 到 Dubbo 到 gRPC

选 RPC 框架，本质是在“性能、跨语言能力、治理能力、生态”之间做取舍。我把几个有代表性的框架放一起对比。

6.1 Java RMI：为什么它被边缘化

Java RMI 是最早期的 RPC 方案之一，Java 原生支持，写起来也方便，但它的核心问题是“太 Java 了”：

使用 Java 原生序列化，序列化结果里带有类名等元信息，体积大；
只支持 Java 到 Java，跨语言基本不可能；
默认端口是 1099，而且是随机动态端口（Registry 和 Unicast 对象端口），在防火墙和云环境里部署非常痛苦；
Java 原生序列化还是反序列化漏洞的重灾区，历史上有多个高危 CVE。

很多人问“Java RMI 的并发接入性能和 RPC 框架的差别怎么样”，答案很直接：Java RMI 在现代高并发场景下，序列化耗时和连接管理就是瓶颈，和 Dubbo/gRPC 的并发能力不在一个量级。它不是不能用，而是维护成本和安全风险太高了。

之所以现在还能听到 Java RMI，多半是因为老系统里还留着 EJB 时代的遗产，或者某些中间件底层仍在用它做管理面通信。新项目完全没有理由选它。

6.2 Dubbo 的定位：Java 生态里的治理型 RPC

Dubbo 在国内 Java 生态里地位特殊。它最早由阿里开源，设计目标不是单纯的“远程调用”，而是“服务治理”——注册中心、负载均衡、熔断降级、路由规则、可视化管控台，这些能力都是现成的。

选 Dubbo 的团队通常是：

技术栈高度统一，全 Java；
服务数量多，需要治理能力；
已经在用 Nacos / Zookeeper / 注册中心体系。

Dubbo 的短板也很明显：默认协议走自定义 TCP，跨语言支持薄弱。虽然官方有 triple 协议（基于 HTTP/2 + Protobuf）支持跨语言，但生态和工具链相比 gRPC 还是要逊色一些。

6.3 gRPC：跨语言与云原生的默认答案

gRPC 的核心优势是“中立”和“标准”：

多语言代码生成能力最强；
基于 HTTP/2，可以在现有网络设施上跑；
在 Kubernetes、Istio 等云原生生态里支持最好；
社区活跃，CNCF 项目里大量接口都在往 gRPC 迁移。

代价是：服务治理能力（限流、熔断、链路追踪）不像 Dubbo 那样“开箱即用”，需要自己接微服务治理体系；加上二进制编码对排障工具要求高，出了问题抓包后要先转成可读格式才能分析。

6.4 一张表对比主流 RPC 框架

对比维度	Dubbo	gRPC	Thrift	Java RMI
跨语言能力	弱（默认协议）	强	强	仅 Java
序列化	Hessian2 等	Protobuf	Thrift 自研	Java 原生
传输协议	自定义 TCP	HTTP/2	自定义 TCP	JRMP
服务治理	内置	需集成	无	无
流式调用	阿里扩展支持	支持 4 种模式	支持	不支持
多语言客户端生成	一般	优秀	良好	无
最佳场景	Java 微服务群	多语言、云原生	多语言、性能敏感	老旧系统维护

另外提一下 Thrift，它是 Facebook 开源的老牌 RPC 框架，性能和跨语言能力都不错，但这些年社区活跃度明显不如 gRPC，新项目里选它的团队少了很多。

选型上没有“最好”，只有“最合适”。我的建议是：如果你们是纯 Java 团队且服务治理要求高，Dubbo 很顺手；如果代码库有多语言、或者要往云原生走，优先考虑 gRPC。

7. 落地时容易踩的坑：超时、SSL 报文和依赖安装

最后写几个我实际遇到过、报错信息看起来吓人、但根因很好找的问题。这几个坑来自真实线上案例，也和很多人在社区搜到的高频报错一致。

7.1 `cannot finish rpc call in 30 seconds` 的完整排查思路

这类超时报错几乎是所有 RPC 调用方都会遇到的。出现这个报错，不要第一时间怀疑网络，而是按下面的顺序排查：

看服务端有没有收到请求。服务端日志里找不到请求，说明问题在网络或负载均衡层；能找到，说明问题在服务端自身。
看服务端处理耗时。耗时普遍很高，去看慢查询、GC、线程池、连接池。
看客户端超时配置是否合理。是不是所有接口都共用了一个超时值？批量查询接口 30 秒不够很正常。
看有没有触发重试风暴。客户端配置了重试，超时后又重试，服务端压力翻倍，形成恶性循环。
看连接池是否被打满。连接池满了，新请求排队等待空闲连接，表面上也是“超时”。

我上次排的那个问题，就是第 2 步和第 4 步叠加：服务端数据库连接池耗尽，处理变慢，客户端 3 次重试，直接把服务端打垮。修好连接池、关闭重试之后，恢复稳定。

注意：RPC 框架重试默认都是要慎用的。如果下游是“非幂等操作”，重试可能导致重复下单、重复扣款。重试策略要配合幂等设计一起做。

7.2 `error: rpc failed; curl 56 openssl ssl_read` 不是 gRPC 的锅

这个报错经常出现在 git push 或 git clone 大仓库时，看起来带“rpc”和“ssl_read”，很容易让人误以为是 RPC 框架的问题，实际上它是 Git Smart HTTP 协议在 SSL 层读数据失败。

curl 56 的意思是“接收数据失败”，openssl ssl_read 报错说明 TLS 会话在传输过程中被中断。常见原因：

公司代理或防火墙对长连接做了空闲超时；
大文件上传超过代理的缓冲限制；
网络不稳定导致 TLS 连接中断；
Git 的 HTTP/2 实现与某些服务端兼容性有问题。

解决办法按顺序试：

bash复制# 关闭 Git 的 HTTP/2，回到 HTTP/1.1
git config --global http.version HTTP/1.1

# 增大 post buffer，让 Git 发送大对象时不用拆太碎
git config --global http.postBuffer 524288000

# 关闭 SSL 校验（只在明确是内网代理证书问题时测试用，不建议长期开）
git config --global http.sslVerify false

大多数场景下，http.version HTTP/1.1 和 http.postBuffer 调大就能解决。如果还不行，检查代理设置：env | grep -i proxy，确认 Git 是否走了不稳定的代理。

7.3 protobuf 安装和版本一致性

很多第一次用 gRPC 的人会卡在 protoc 安装上。这里有几个高频问题：

直接用 apt/yum 装的 protoc 版本过旧。某些发行版仓库里的 protoc 还停留在 3.x 早期版本，而 gRPC 新版本需要 protoc 3.21+ 或 4.x。安装前先确认 protoc --version，最好从官方 GitHub Releases 下载指定版本，或者用 brew install protobuf（macOS）。
protoc 插件和 protoc 版本不匹配。生成 gRPC 代码需要 protoc-gen-go-grpc、protoc-gen-java 等插件，插件版本必须和 protoc 主版本对应，否则会出现 protoc-gen-go-grpc: program not found or is not executable。
运行时库版本和生成代码版本不一致。proto 文件用某种版本生成了代码，但项目依赖的 protobuf runtime 是另一个版本，运行时大概率报 InvalidProtocolBufferException 或反序列化异常。锁定版本的关键是把 proto 生成代码和 protobuf runtime 放进同一个依赖管理流程，比如 Java 里用 Maven 的 protobuf-maven-plugin 统一管理，Go 里用 protoc-gen-go 的版本约束。

另外一个细节：proto 文件的 import 路径。项目里多个 proto 互相引用时，protoc 的 --proto_path（也叫 -I）必须指向正确的根目录，否则会报“file not found”。我见过太多人卡在这个地方，其实先 find . -name "*.proto" 确认一下目录结构就清楚了。

和我个人经验相关的最后一个建议：proto 文件一定要进代码评审。它不是普通的“配置”，而是线上契约。字段编号、字段类型、package 命名、兼容性设计都要像设计 API 一样认真对待。很多 RPC 事故的根源不是框架不行，而是 proto 文件在评审阶段就没有被重视。