gRPC压缩需客户端和服务端显式配置编码器，仅设WithCompressor不够；gzip是Go原生唯一支持格式，压缩阈值建议5KB以上，且须通过grpc-encoding头验证生效。
gRPC 压缩开关在哪设？WithCompressor 和 WithDecompressor 不是万能钥匙
Go 的 gRPC 客户端和服务端默认都不启用压缩，想用必须显式配置。但光调 WithCompressor 不够——服务端得注册解压器，客户端得注册压缩器，两边不匹配会静默失败或报 rpc error: code = Internal desc = grpc: decompressor is not installed for content-encoding "gzip"。
-
grpc.WithCompressor(gzip.NewCompressor())只影响当前 client conn，不是全局开关 - 服务端需在
grpc.Server初始化时传入grpc.KeepaliveParams以外的选项：grpc.UnknownServiceHandler不管压缩，真正起作用的是grpc.StreamInterceptor或直接注册：grpc.RegisterCodec已废弃，改用grpc.AddEncoding注册编码器（如grpc.AddEncoding("gzip", gzip.Name, gzip.NewCompressor, gzip.NewDecompressor)） - 注意：gRPC 的压缩是 per-RPC 的，由
grpc-encodingheader 控制，不是 HTTP-level 压缩；gzip是唯一被 Go 标准库原生支持的，snappy、zstd需第三方包且双方都得引入
什么时候该开压缩？看 payload 大小，别看 QPS
压缩不是“开了就省带宽”，它把 CPU 换成网络字节。实测表明：单条 message 小于 1KB 时，开启 gzip 反而增加延迟（压缩耗时 > 传输节省），且可能因小包变大触发更多 TCP ACK；超过 5KB 后收益才明显。
- 典型适合场景：
proto中含bytes字段（如图片 base64、日志批量上报、序列化后的结构体切片） - 不适合场景：高频低载荷接口（如心跳、状态查询），或 message 已经是压缩格式（如传
.zip内容再套 gzip 属于重复压缩） - 验证方法：用
grpcurl -plaintext -v localhost:8080 proto.Service/Method看请求/响应头里的grpc-encoding和实际 body size 变化，比看 CPU 使用率更直接
grpc.UseCompressor 和 grpc.CallOption 的优先级怎么算？
压缩策略按「调用粒度 > 连接粒度 > 服务端默认」生效，且只对 unary 和 streaming 的 payload 起作用，metadata 不压缩。
- 最高优：unary call 时传入
grpc.UseCompressor("gzip")，仅本次 RPC 生效 - 中优先：client conn 创建时用
grpc.WithCompressor(gzip.NewCompressor())，所有未显式覆盖的调用走这个 - 最低优：服务端通过
grpc.AddEncoding注册了gzip，但没配默认值，此时若 client 没声明 encoding，server 也不会自动压缩 - 陷阱：
grpc.UseCompressor("snappy")如果 server 没注册snappy编码器，会 fallback 到不压缩，且无错误提示——只能靠抓包确认grpc-encodingheader 是否存在
为什么压了还是慢？检查三个隐藏瓶颈
开了压缩却没提速，大概率卡在非算法层：gRPC 的压缩发生在序列化之后、发送之前，如果 proto message 本身嵌套深、字段多，序列化（Marshal）已占大头，压缩只是锦上添花。
立即学习“go语言免费学习笔记（深入）”；
- CPU 绑定：gzip 默认用同步压缩，高并发下 goroutine 会被阻塞；可换
pgzip（支持 goroutine 池）或限制并发数，但要注意pgzip不是标准库，需双方一致使用 - 内存分配：每次压缩都 new []byte，小消息频繁调用易触发 GC；生产环境建议复用
sync.Pool管理压缩 buffer - 协议栈干扰：Kubernetes Service 或 Envoy 代理可能重写 header、禁用 compression，或强制 buffer 大小限制（如 Istio 默认 max frame size=16MB），导致压缩后超限被截断
