protobuf本身不提供压缩功能，所谓“2–10倍压缩比”实为与json/xml文本字节长度对比所得；真实压缩比须显式计算len(original_bytes)/len(proto.marshal(...))，且必须基于同一[]byte输入、排除http头等干扰。
Protobuf本身不提供压缩比，必须手动计算
Protobuf序列化输出的是紧凑二进制，但「压缩比」不是它内置的指标——它只是编码格式，不是压缩算法。你看到的“Protobuf压缩比达2–10倍”，其实是和原始JSON/XML文本对比得出的，而非自身有压缩功能。真实压缩比必须由你显式计算：len(original_bytes) ÷ len(proto.Marshal(...))。关键陷阱在于：别拿字符串长度、文件大小或解码后内容去比，必须基于同一份[]byte输入，且确保proto.Marshal结果未被额外包装（如HTTP头、自定义信封）。
用proto.MarshalOptions控制序列化体积，影响压缩比基准值
同一份proto消息，不同proto.MarshalOptions参数会产出不同长度的bytes，直接影响压缩比分母。忽略这点会导致测量不可复现：
-
AllowPartial: true—— 跳过未设置的optional字段（proto3中默认行为，但旧生成代码可能冗余写入） -
Deterministic: true—— 固定map/repeated顺序，避免因排序差异导致字节流波动（对gzip等后续压缩影响显著） -
UseCachedSize: true—— 仅加速Marshal，不改变输出字节，别误以为它能“压缩”
示例：
opts := proto.MarshalOptions{
AllowPartial: true,
Deterministic: true,
}
data, _ := opts.Marshal(msg)
ratio := float64(len(srcJSONBytes)) / float64(len(data)) // 注意：srcJSONBytes是原始JSON转成[]byte，非字符串长度
真正压缩需叠加gzip/zlib，注意协议头尾开销
若你实际想测“Protobuf + gzip”的端到端压缩效果，不能只调proto.Marshal再套gzip.Writer就完事。常见错误包括：
- 没调
gw.Close()——gw.Flush()不保证压缩完成，buf里可能残留未压缩数据 - 留着
gw.Header.Name或Comment—— 默认为空，但某些环境可能注入值，多出10~30字节 - 混淆gzip和zlib协议 —— 同样内容，gzip输出比zlib固定多约10字节（header+trailer差异），小数据下这个差值会显著拉低压缩比
正确做法：
var buf bytes.Buffer gw := gzip.NewWriter(&buf) gw.Header.Name = "" gw.Header.Comment = "" _ = gw.Write(data) // data是proto.Marshal结果 _ = gw.Close() compressedLen := buf.Len()
移动端或包体积敏感场景，得换生成器而非只调参数
如果你发现proto.Marshal结果还是太大，MarshalOptions已无优化空间——说明问题在生成代码本身。标准google.golang.org/protobuf生成的代码含反射支持、完整Descriptor逻辑，体积大且字段布局不紧凑。这时必须换代码生成器：
-
protoc-gen-gotiny：生成更短变量名、禁用反射、精简struct字段，典型减少15–30%序列化体积，但要求两端都用它生成且版本一致 - 别碰
gogoproto：已归档，兼容性差，新项目风险高
重点：换生成器后，proto.Unmarshal会拒绝非标准格式，必须全链路统一，否则直接panic。
proto.Marshal之后加的那层gzip，才是真正决定最终字节数的关键。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
