为什么用 Protobuf
选择 Protocol Buffers（protobuf）作为通信/存储格式，核心原因是它在性能、跨语言、接口契约、演进能力四个维度上的综合优势。
1. 高性能与紧凑编码
- 二进制编码：相比 JSON/XML 文本格式，体积通常小 30%–50%，序列化/反序列化快 2–10 倍；
- Tag-Length-Value 结构：按字段编号 + 变长整数（Varint）存储，没有 JSON 的键名字符串冗余——这是体积优势的主要来源。
2. 跨语言与代码生成
- 官方支持 C++、Java、Python、Go 等主流语言，社区支持 Rust、Swift 等；
- 一份
.proto定义，protoc自动生成各语言的结构体/类——异构系统间通信不需要手写解析，减少错误。
3. 强类型接口契约
.proto是数据结构的权威定义，字段类型显式声明（int32/string/…），编译期即校验；- 版本兼容：字段编号 + optional/repeated 规则保证向后/向前兼容，老代码忽略未知字段，新代码能读旧数据。
4. 可扩展性
- 新增字段不破坏旧版解析（旧客户端自动忽略）；
- 支持嵌套消息、枚举、oneof 等建模复杂结构。
5. RPC 生态
- protobuf 是 gRPC 的默认数据格式，两者深度集成；
- 支持流式请求/响应（gRPC Stream），是微服务通信的事实标准。
与其他协议对比
| 特性 | protobuf | JSON | XML | Thrift/Avro |
|---|---|---|---|---|
| 编码效率 | 高（二进制） | 低（文本） | 最低 | 高 |
| 解析速度 | 快 | 慢 | 最慢 | 快 |
| 跨语言 | 优秀 | 优秀 | 优秀 | 优秀 |
| 强类型 Schema | 必须 | 可选 | 可选（XSD） | 必须 |
| 人类可读 | 差（需工具） | 好 | 好 | 差 |
适用场景
- 微服务通信：gRPC 服务间数据传输；
- 存储序列化：Kafka 消息、数据库二进制列；
- 移动端：省流量省电量；
- 游戏开发：高频网络同步需要低延迟编码。
注意事项
- 调试困难：二进制不可直接阅读，需要工具（
protoc --decode_raw）； - 不适合人类可读场景：REST API、需要 curl 调试的接口别用它；
- Schema 管理成本：要维护 .proto 的版本、依赖和代码生成流程（buf 工具链可以简化）；
- 体积优势有边界：数据小且字段名短时，JSON 压缩后差距不大；大量重复结构时才显著。