gRPC服务端启用Gzip压缩需三处修改：注册gzip编码器（grpc.RegisterCodec）、配置ServerOption（MaxRecv/SendMsgSize调大）、客户端同步设置WithCompressor和WithDecompressor。
gRPC服务端启用Gzip压缩要改哪几个地方
Go的grpc-go默认不开启任何压缩，必须显式配置。关键不在HTTP层，而在gRPC自身的编码器注册和Server/Client选项里。
常见错误是只配了WithCompressor但漏掉WithDecompressor，导致客户端收不到解压后的响应；或者把压缩逻辑写在中间件里——gRPC的压缩必须在Stream层介入，中间件没用。
- 服务端：用
grpc.Creds之外的grpc.KeepaliveParams无关，重点是grpc.ServerOption中的grpc.MaxMsgSize要同步调大（压缩后消息变小，但解压前缓冲区仍按原始大小预估） - 客户端：必须同时设置
grpc.WithCompressor和grpc.WithDecompressor，否则会报unknown compression format - 压缩算法只支持
gzip和snappy（后者需额外导入google.golang.org/grpc/encoding/snappy），zstd等需自己注册编码器
示例服务端启动片段：
server := grpc.NewServer(
grpc.KeepaliveParams(keepalive.ServerParameters{}),
grpc.MaxRecvMsgSize(32 * 1024 * 1024),
grpc.MaxSendMsgSize(32 * 1024 * 1024),
)
// 必须手动注册，gRPC不自带gzip注册
grpc.RegisterCodec(codec.NewGZIPCodec())客户端发起带Gzip的gRPC调用时为什么还走明文
不是所有方法都自动压缩——gRPC只对消息体（proto.Message序列化后的内容）压缩，且仅当请求头明确声明grpc-encoding: gzip时才触发。这个头由客户端SDK根据配置自动加，但前提是：方法本身没被禁用压缩、消息尺寸超过阈值、且服务端支持该编码格式。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 默认阈值是1KB（
grpc.DefaultCompressorThreshold），小于它不会压缩，避免小包压缩反而膨胀 - 如果用了
grpc.EmptyCall或返回google.protobuf.Empty，因序列化后长度为0，必然不压缩 - 检查WireShark或
grpclog日志，确认请求Header里有grpc-encoding: gzip；没有的话说明WithCompressor没生效或被覆盖 - 注意
WithCompressor必须在grpc.Dial时传入，不能在Invoke或NewStream时动态指定
自定义Gzip压缩级别影响性能和兼容性吗
标准grpc-go的GZIPCodec用的是gzip.DefaultCompression（等级6），不暴露参数。想调压缩比就得自己实现encoding.Compressor接口，但要注意：服务端和客户端必须用完全一致的压缩级别，否则解压失败会静默丢包或返回io.ErrUnexpectedEOF。
- 级别1（
gzip.BestSpeed）适合高吞吐低延迟场景，CPU开销下降约40%，但压缩率可能只比不压好10%～20% - 级别9（
gzip.BestCompression）对小消息意义不大，反而增加首字节延迟；对>1MB的protobuf payload才值得尝试 - 不同Go版本的
compress/gzip行为略有差异，Go 1.21+修复了多goroutine并发压缩时的内存泄漏，旧版本慎用高级别
自定义实现只需重写Compress和Decompress两个方法，Name()返回"gzip"才能被识别。
压缩后出现“message decode failed”或“invalid wire format”
这不是压缩问题，是解码顺序错了。gRPC的压缩发生在序列化之后、发送之前；解压必须在反序列化之前完成。如果手动调了proto.Unmarshal再解压，或者把压缩数据当成原始bytes传给jsonpb，就会出这类错。
- 确保没在拦截器（
UnaryInterceptor）里对req/resp做proto.Marshal或Unmarshal——压缩流不能被提前解包 - 服务端日志若出现
failed to unmarshal request: proto: can't skip unknown wire type 6，基本是客户端发了gzip但服务端没注册GZIPCodec，导致把压缩后的二进制当proto解析 - 用
grpcurl测试时，默认不带压缩，得加-protoset和-plaintext还不够，必须指定-rpc-header 'grpc-encoding: gzip'才模拟真实行为
真正难调试的点在于：压缩失败往往不报错，只是返回乱码或空结构体。建议在开发期用grpc.WithBlock() + 日志打点，确认Compress和Decompress函数确实被调用过。
