gRPC 比 JSON HTTP 更快但压测差距小，主因是连接未复用、HTTP/2 未启用或降级、客户端频繁 Dial；protobuf 瓶颈可通过 gogo/protobuf、手动 BinaryMarshaler 和缓冲区复用优化；context timeout 错误设置导致下游超时雪崩；熔断无效因依赖超时而非失败率，应改用并发限流+自适应超时。
为什么 gRPC 比 JSON HTTP 更快，但实际压测没差多少？
根本原因常是服务端未关闭 Keep-Alive 或客户端复用 *http.Client 不当，导致每次调用都新建 TCP 连接。gRPC 底层虽用 HTTP/2，但若 TLS 握手耗时高、或服务端未启用 HTTP/2（比如 Nginx 前置代理未透传），gRPC 就会退化成多路复用的 HTTP/1.1，失去流控和头部压缩优势。
- 确认服务端监听明确启用了 HTTP/2：
lis, _ := net.Listen("tcp", ":8080") srv := grpc.NewServer() // 不要漏掉这行 grpc.EnableTracing = false // 非调试期关掉 - Nginx 代理 gRPC 必须配置
http2和grpc_pass，不能用proxy_pass http://...；否则连接被降级 - 客户端务必复用
*grpc.ClientConn，不要每次调用都grpc.Dial()—— 这个操作本身含 DNS 解析、TLS 握手、HTTP/2 协商，开销远超一次 RPC
如何让 protobuf 序列化不成为瓶颈？
默认 proto.Marshal() 是反射实现，小消息不明显，但字段超 20 个、嵌套深、或高频调用（>10k QPS）时，GC 压力和 CPU 占用会陡增。尤其当结构体含 []byte 或 map[string]string 且长度波动大时，序列化缓冲区反复分配易触发 GC。
- 用 gogo/protobuf 替代官方
protoc-gen-go，生成代码带MarshalUnsafe和零拷贝Size方法 - 对高频小消息（如心跳、状态上报），手动实现
encoding.BinaryMarshaler，绕过 protobuf 运行时 - 避免在 proto message 中定义大字段（如原始图片 base64）；改用
bytes字段 + 客户端预分配make([]byte, 0, 4096)复用缓冲区
context.WithTimeout 传错地方，为什么请求延迟翻倍？
常见错误是在服务端 handler 开头就写 ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，然后把新 ctx 传给下游 gRPC 调用。问题在于：这个 timeout 是从当前时刻起算，而非上游请求开始时刻。若本服务已处理 3 秒，再设 5 秒，下游只剩 2 秒可用，极易超时重试，形成雪崩。
- 始终使用上游传入的
ctx直接调用下游，不要重设 deadline —— gRPC 会自动透传timeout和cancel信号 - 仅在必须限制某段**内部逻辑**（如 DB 查询、本地缓存加载）时，才用
context.WithTimeout，且 timeout 值应显著小于上游剩余时间（建议 ≤ 1/3） - 用
grpc.SendMsg/RecvMsg级别埋点验证：若RecvMsg耗时正常但SendMsg突增，大概率是下游因 timeout 被 cancel 导致重传
为什么加了熔断还是扛不住突发流量？
标准熔断器（如 sony/gobreaker）基于失败率统计，但微服务间调用失败常是超时（context.DeadlineExceeded），而超时本身是下游负载过高导致 —— 此时失败率未必超标，熔断器不触发，流量继续涌入，形成正反馈恶化。
立即学习“go语言免费学习笔记（深入）”；
- 改用并发控制（concurrency limit）+ 排队：用
golang.org/x/sync/semaphore限制单机最大并发 outbound 请求，比纯失败率更前置 - 对关键依赖（如用户中心、订单服务），在 client 层加
adaptive timeout：根据最近 10 次 P95 延迟动态调整本次调用的context.WithTimeout - 禁用 gRPC 的默认重试（
EnableRetry: true）—— 微服务拓扑中，重试放大效应远大于收益，应由业务层统一决策是否重试
