gRPC服务端启用zstd压缩需先引入github.com/klauspost/compress/zstd（v1.5+），再通过grpc.RPCCompressor和grpc.RPCDecompressor注册编码器与解码器，缺一不可；snappy因在1–10KB区间压缩耗时稳定约5μs，较gzip更适配高频小请求。
gRPC服务端怎么启用zstd压缩
zstd不是gRPC默认支持的算法，必须手动注册后才能用。不注册就直接传zstd.Name会报错compressor not registered，这是最常卡住的第一步。
- 先引入
github.com/klauspost/compress/zstd（推荐v1.5+），别用老版本——它对Go 1.21+的io.Reader接口适配有问题 - 调用
grpc.RPCCompressor和grpc.RPCDecompressor注册，注意两个都要注册，只注册一个会导致客户端/服务端解压失败 - 服务端配置示例：
zstdCompressor, _ := zstd.NewWriter(nil) s := grpc.NewServer( grpc.RPCCompressor(grpc.NewCompressor("zstd", zstdCompressor, zstd.Decompressor{})), ) - 别在
WithCompressor里传zstd.Compressor{}——那是旧版API，新版gRPC要求实现encoding.Compressor接口
snappy为什么比gzip更适合高频小请求
不是snappy“更快”，而是它在1–10KB消息区间内，压缩耗时几乎恒定在~5μs，而gzip在同样大小下可能波动到50–200μs。这对P99延迟敏感的服务很关键。
- snappy不追求高压缩率，
10KB JSON压缩后约7.2KB，gzip能压到3.8KB，但多花的150μs在QPS过万时会直接拖垮CPU - 实测中，当单次响应稳定在
2KB以内、RT要求时，snappy的吞吐比gzip高37%，且<code>go tool pprof显示CPU热点从gzip.compress转移到了业务逻辑本身 - 注意：snappy不能解压非snappy压缩的数据，客户端必须显式声明
grpc.UseCompressor(snappy.Name)，否则服务端即使支持也返回未压缩数据
zstd参数怎么调才不白费CPU
zstd的WithEncoderLevel默认是ZSTD_DEFAULT_CLEVEL（3级），但对protobuf二进制数据，设成1或2反而更优——压缩率只降3–5%，速度却快2.1倍。
- 别盲目上
ZSTD_BEST_SPEED（-5级）：它会强制用哈希表查重，小消息下内存分配开销反超压缩收益 - 对
100KB+日志类payload，用WithEncoderLevel(zstd.SpeedDefault)（默认1级）+WithEncoderCRC(true)更稳，CRC能避免网络丢包导致的静默解压错误 - zstd的
Decoder必须复用，每次new会重建状态机——在handler里写zstd.NewReader(resp.Body)是典型错误，应提前建好池：sync.Pool{New: func() interface{} { return zstd.NewReader(nil) }}
客户端不配UseCompressor就等于没压缩
gRPC的压缩是双向协商机制，服务端支持≠自动启用。客户端不声明，服务端永远按未压缩路径走，连HTTP/2的content-encoding头都不会发。
立即学习“go语言免费学习笔记（深入）”；
- 全局设置最省事：
grpc.WithDefaultCallOptions(grpc.UseCompressor(zstd.Name))，但要注意——它对streamRPC无效，流式调用必须每个Send前单独加grpc.UseCompressor - 如果部分接口不想压缩（比如上传
bytes字段已含JPEG），得用grpc.EmptyCallOption覆盖，默认选项不会智能跳过 - 验证是否生效：抓包看HTTP/2帧里的
content-encoding是否为zstd或snappy，而不是只查服务端日志有没有“compress”字样
压缩算法选型真正的复杂点不在“哪个快”，而在于你能不能把compressor生命周期管住、把UseCompressor塞进所有调用路径、以及敢不敢对proto.Message结构做针对性裁剪——毕竟再好的压缩，也压不过一个冗余的repeated string metadata = 99;字段。
