gRPC 默认不重试，需显式配置重试策略；Protobuf 字段编号影响序列化体积与兼容性，高频字段用1–15；健康检查与Keepalive是连接存活底线；拦截器是统一注入容错逻辑的唯一入口。
gRPC 默认不重试，必须显式配置重试策略
很多人以为 gRPC 会像 HTTP 客户端一样自动重试失败请求，结果在线上遇到 UNAVAILABLE 或 DEADLINE_EXCEEDED 就直接报错，服务雪崩一触即发。gRPC 默认关闭重试，这是设计使然——它把语义控制权交还给开发者。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 客户端连接时用
grpc.WithDefaultServiceConfig注入 JSON 配置，例如：{"retryPolicy":{"maxAttempts":3,"initialBackoff":"0.1s","maxBackoff":"2s","backoffMultiplier":2,"retryableStatusCodes":["UNAVAILABLE","RESOURCE_EXHAUSTED"]}} - 避免在 handler 里手动
for循环重试，这会绕过 gRPC 的上下文传播和超时控制 - 重试只对幂等方法安全，
rpc CreateUser这类非幂等操作必须加业务层去重（如 idempotency key） - 注意 Go 版本差异：1.21+ 支持
grpc-gov1.60+ 的新重试 API，旧版本需用grpc_retry第三方包
Protobuf 字段编号不是“随便填”，影响序列化体积和兼容性
字段编号小，编码后占字节少——这是 Protobuf wire format 的硬规则。但更关键的是，编号一旦发布就不能改，否则老客户端解析新服务就会 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 高频字段（如
user_id、timestamp）用 1–15 编号；低频或可选字段（如metadata）从 16 开始 - 删除字段必须用
reserved，例如：reserved 3, 7;，而不是直接删掉那行int32 xxx = 3; - 新增字段一律设为
optional（proto3 中默认就是 optional），不要用repeated模拟可选字段 -
map<string, string>和google.protobuf.Struct是预留扩展的推荐方式，比不断加新字段更可持续
健康检查 + Keepalive 不是“锦上添花”，而是连接存活的底线
没有健康检查的 gRPC 连接，在节点宕机后可能维持数分钟“假活”状态，请求持续打到已死节点，直到 TCP 层超时（默认 2 小时）。这不是理论风险，是线上真实发生的流量倾斜根源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务端启动时启用
grpc.KeepaliveParams，例如：keepalive.ServerParameters{Time: 30 * time.Second, Timeout: 10 * time.Second} - 客户端创建连接时传入
grpc.WithKeepaliveParams，并设置PermitWithoutStream: true，否则空闲连接会被断开 - 务必配合服务发现使用——单独开 Keepalive 不解决节点下线感知问题，必须和 Consul/etcd 的 TTL 注册联动
- 别信 “本地开发没出问题”，Kubernetes Pod 重启、云主机网络抖动才是常态场景
拦截器不是日志中间件，是统一注入容错逻辑的唯一入口
把超时、熔断、指标埋点写在每个 handler 里，等于放弃一致性保障。gRPC 拦截器是唯一能保证所有 RPC 调用都经过同一套可靠性逻辑的地方。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务端拦截器中检查
ctx.Deadline()，并在 handler 执行前做select { case ，别等业务逻辑跑完才发现超时 - 客户端拦截器统一加
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，而不是让每个调用方自己控制 - 熔断器（如
sony/gobreaker）必须放在拦截器里，且状态共享——不能每个连接实例一个熔断器 - 可观测性字段（trace_id、span_id）必须从拦截器注入
metadata.MD，否则链路追踪断层
真正的协议解析性能瓶颈，往往不在编解码本身，而在于连接管理是否及时剔除故障节点、重试是否覆盖常见 transient error、以及字段变更是否破坏二进制兼容性。这些细节不写进 proto 文件，也不出现在生成代码里，但每一条都决定服务能不能扛住真实流量。
