grpc客户端启用gzip压缩需配置withcompressor而非header；服务端默认自动解压，但若误配withdisablecompression()会导致解析失败；压缩仅作用于message body，应按method粒度控制并实测收益。
gRPC 客户端启用 Gzip 压缩要配 WithCompressor，不是加 header
很多同学试过手动在 metadata 里塞 grpc-encoding: gzip，结果没用——gRPC 的压缩开关不在传输层 header，而是在底层编码器注册和调用链路里。客户端必须显式传入压缩器实例，服务端也得提前注册对应解压能力，否则请求直接被拒绝或静默降级为不压缩。
实操建议：
- 客户端初始化
grpc.Dial时，用grpc.WithCompressor(grpc.NewGZIPCompressor()) - 服务端启动
grpc.Server时，加grpc.RPCServerOption(grpc.MaxConcurrentStreams(100))不影响压缩，但必须确保没禁用压缩（默认开启） - 如果用的是 Go 1.21+ 和 grpc-go v1.60+，
grpc.NewGZIPCompressor()已废弃，改用grpc.WithCompressor(gzip.Compressor{})（注意是gzip.Compressor{}，不是字符串） - 别依赖
Accept-Encoding或自定义 header 触发压缩——gRPC 不走 HTTP/1.1 那套协商逻辑
服务端是否自动解压？看 grpc.Server 初始化时有没有禁用 grpc.WithDisableCompression()
默认情况下，gRPC 服务端会自动识别并解压带 grpc-encoding: gzip 的请求体，但这个行为可以被全局关闭。一旦你在 grpc.NewServer() 里误加了 grpc.WithDisableCompression()，哪怕客户端拼命压缩，服务端也只当普通二进制流处理，后续反序列化直接失败，报错类似 proto: can't skip unknown wire type 6。
常见错误现象：
- 客户端日志显示“sent compressed”，服务端收到后解析 panic
- Wireshark 抓包看到 payload 明显变小，但业务逻辑收不到完整 message
- 错误信息里出现
invalid encoding或failed to unmarshal，而非网络超时
检查点：
- 搜索代码里所有
grpc.NewServer(调用，确认没传grpc.WithDisableCompression() - 服务端不需要手动调
gzip.NewReader——那是自己造轮子，gRPC 底层已封装好 - 压缩只作用于 message body，metadata 和 header 永远不压缩
跨机房场景下，Gzip 压缩比和 CPU 开销得实测，别信理论值
压缩对延迟的影响不是单向的：小消息（ 网络节省时间；大消息（>50KB）才明显受益。跨机房链路 RTT 高、带宽窄，但不同机房间压缩收益差异极大——比如金融类 protobuf 字段重复多，压缩比常达 70%；而加密后的 token 或 base64 图片字段，压缩比可能只有 2%～5%，还白耗 CPU。
实操建议：
- 上线前用真实 payload 做 AB 测试：开 / 关压缩，监控
grpc_client_handled_latency_ms和grpc_server_msg_received_bytes_total - Go 服务可设
GODEBUG=gctrace=1观察 GC 压力变化，压缩高频触发 GC 是常见坑 - 别全局开压缩，按 method 控制更稳妥：用
grpc.UseCompressor+ 自定义拦截器，对*_List类接口开，对*_Ping关
grpcurl 调试时看不到压缩效果？它默认不发压缩请求
grpcurl 命令行工具本身不支持发送 gzip 压缩 payload，即使你加了 -H 'grpc-encoding: gzip'，它也不会真正压缩 body，只是透传 header。所以用 grpcurl 测出来的带宽/延迟，不能代表生产环境真实压缩表现。
替代方案：
- 写个最小 Go client，用
grpc.Dial+WithCompressor复现调用，抓包对比 payload size - 服务端打日志：在 unary interceptor 里打印
ctx.Value(grpc.Peer{}).(*peer.Peer).Addr.String()和len(reqBytes)，确认收到的是压缩后长度 - 用
tcpdump+grpc_cli（非 grpcurl）或自研压测工具验证，避免调试工具引入偏差
跨机房通信里，压缩算法本身不复杂，难的是判断“什么时候该压、压多少、压了之后谁来扛住 CPU”。这些没法靠配置开关解决，得看实际 payload 分布和机器负载水位。
