gRPC 中字符串字段是否值得压缩？看实际序列化后体积
字符串字段本身不决定压缩价值，真正起作用的是它在 Protobuf 编码后的字节长度。比如一个 string 字段存的是 JSON 片段或 HTML 片段，序列化后可能达 5KB；而另一个存的是用户昵称 "alice"，proto.Size() 返回才 8 字节——后者压了反而膨胀，还白耗 CPU。
实操建议：
- 别凭字段类型判断，一律用
proto.Size(&msg)测序列化后大小，这是唯一可靠依据 - 对
bytes字段要特别小心：如果里面已经是 gzip 压缩过的二进制（如上传的 .zip 文件），再套一层 gRPC gzip 就是重复压缩，体积不变、CPU 白烧 - 含大量重复前缀的字符串（如日志行中的固定路径
/var/log/app/...）gzip 压缩率通常 >60%；纯随机字符串（如 UUID）基本压不动
gRPC 默认不压缩 string，必须显式声明 encoding
哪怕服务端注册了 gzip.Compressor，客户端不发 grpc-encoding: gzip 请求头，字符串照样明文传。这不是 bug，是 gRPC 的协商机制：压缩是 per-RPC 的，由客户端单方面发起请求时指定。
常见错误现象：
- 服务端配了
grpc.RPCCompressor(gzip.Compressor{})，但客户端只写了grpc.Dial(..., grpc.WithCompressor(gzip.NewCompressor()))—— 这个WithCompressor是无效写法，新版 gRPC 已废弃 - 客户端用了
grpc.WithDefaultCallOptions(grpc.UseCompressor(gzip.Name))，但某次调用又手动传了grpc.CallOption(nil)，把默认选项覆盖掉了 - 用
grpcurl测试时忘了加-rpc-header 'grpc-encoding: gzip'，结果看到的全是明文
字符串密集型 payload 该选 gzip 还是 snappy？
文本类字符串（JSON、XML、日志行）在 1–10KB 区间，snappy 和 gzip 的压缩率差约 2.3×（gzip 更小），但 snappy 压缩耗时稳定在 ~5μs，gzip 波动在 50–200μs。这意味着：如果你的接口 P99 RT 要压到 10ms 以内，且平均响应含 3KB 字符串，snappy 是更稳的选择。
使用条件：
- 选 snappy 必须两端都引入
google.golang.org/grpc/encoding/snappy，并注册：grpc.RegisterCodec(snappy.NewCodec()) - 客户端调用时仍需显式
grpc.UseCompressor(snappy.Name)，不能依赖服务端“自动适配” - gzip 在 >5KB 后收益明显，但要注意：Protobuf 对短字符串本就编码高效，真正需要压缩的往往是嵌套 repeated string 或 map
这类结构
压缩阈值必须自己控，gRPC 不会帮你跳过小字符串
gRPC 内部有 grpc.DefaultCompressorThreshold = 1024，但它只对整个 message 生效，不是对单个 string 字段。也就是说，即使你传了一个 20 字节的 string name = 1;，只要整条 GetUserResponse 序列化后超过 1KB（比如带了 10 个其他字段），它仍会被压缩——而这对那个 20 字节字段毫无意义，还拖慢整体。
更合理的做法是封装调用函数：
- 先
size := proto.Size(req)，若size 就跳过 <code>grpc.UseCompressor - 对返回值也做同样判断：
if size > 1024 { opts = append(opts, grpc.UseCompressor(gzip.Name)) } - 别用
len(msg.String())估算——Protobuf 的 varint 编码会让 int 字段长度浮动，proto.Size()才是真实 wire size
最容易被忽略的一点：压缩只作用于 payload，metadata 里的字符串（如 authorization header）从不压缩，无论多长。如果业务里把大 token 放 metadata，再怎么配 gzip 都没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
