第十章：常见误区 —— 真正把 gRPC 用坏，往往不是技术，而是心智偏差

#误区 1：gRPC 一定全面替代 REST

错。

更常见的现实是：

• 外部接口继续 REST
• 内部链路大量 gRPC
• 某些边缘场景两者桥接

它是专线系统，不是全城唯一交通方式。

#误区 2：gRPC 快，是因为“换成二进制就完事了”

错。

真正的收益来自多因素叠加：

• Protobuf
• 代码生成
• HTTP/2 多路复用
• 长连接
• 流式能力
• 更规整的协作方式

如果你的瓶颈根本不在序列化和通信，而在数据库、磁盘、下游慢服务，那么 gRPC 不会神奇治百病。

#误区 3：既然有 streaming，那我就无限往里写

错。

流式 RPC 依然受：

• 流控
• 背压
• 超时 / deadline
• 内存占用
• 消费速度

约束。

流不是黑洞，写进流里不等于对方已经处理完。

#误区 4：字段名改了没事，字段号随便调

大错特错。

在 Protobuf 里，线上的协议身份更看重字段号。
字段删掉后要保留号段，不要复用。

message VehicleEvent {
  reserved 6;
  reserved "legacy_status";

  string vehicle_id = 1;
  string lane_id = 2;
  string status = 3;
}

协议治理差，gRPC 项目会非常痛。

#误区 5：浏览器可以像调用 REST 一样直接跑标准 gRPC

通常不行，或者说不那么直接。

浏览器环境对标准 gRPC 的原生支持不如服务端环境自然，实际工程里常见做法是：

• 走 gRPC-Web
• 或者加代理 / 网关
• 或者对浏览器直接暴露 REST，再在内部转 gRPC

所以别把“服务间通信方案”和“浏览器接口方案”混成一件事。

#误区 6：既然是本地 stub，看起来像本地函数，那就按本地函数心态写

也错。

它看起来像本地调用，但本质仍是远程调用。你必须始终记得这几个问题：

• 可能超时
• 可能取消
• 可能对端不可用
• 可能网络抖动
• 可能部分成功、部分失败

一个非常重要的习惯是：总是设置 deadline/timeout。

reply = stub.GetRoute(
    city_pb2.RouteRequest(origin="A", destination="B"),
    timeout=1.5,
)

不要让客户端无限等下去。

#误区 7：用了 gRPC，就不需要文档和可观测性了

错。

gRPC 只是让合同更正式，不代表你不需要：

• 接口说明
• 调用链追踪
• 监控
• 错误码治理
• 反射 / 调试工具
• 流量治理

专线修得再高级，没有路况监控，照样全城瘫痪。