protobuf适合强契约、跨语言高频通信场景，要求字段严格对齐、序列化体积小、解析快，且需通过.proto定义schema并每次修改后用protoc重新生成代码；avro更适合大数据管道与动态schema演进，依赖schema registry，支持无版本兼容变更；json适用于人眼可读、调试便捷、前端直用等弱契约场景。
Protobuf 适合强契约、跨语言高频通信场景
当服务间调用要求字段严格对齐、序列化体积小、解析快，且团队能接受定义 .proto 文件并生成代码时，Protobuf 是首选。它强制 schema 与数据分离，天然防“字段拼错”“类型不一致”这类运行时才发现的问题。
常见错误现象：AttributeError: 'MyMessage' object has no attribute 'user_id' —— 实际是字段名写成 user_id，但 .proto 里定义的是 user_id_v2，生成代码后根本不存在该属性；或者 Python 端用了旧版生成代码，而服务端已升级字段但没同步重生成。
- 必须用
protoc每次改 schema 后重新生成 Python 类，不能手写或靠运行时推断 -
optional字段在 Python 中默认为None，但若未显式赋值，序列化后该字段不会出现在二进制中（与 JSON 的"key": null行为不同） - 不支持动态字段（如
Map<string any></string>要用google.protobuf.Struct，额外引入依赖） - Python 默认不开启
pybind11加速，小消息影响不大，但高吞吐下建议启用--python_out=.配合protobuf==4.25+和libprotobufC++ runtime
Avro 更适合大数据管道 + 动态 schema 演进
Avro 的核心优势不是“快”，而是 schema 和数据绑定紧密、支持无版本号兼容演进（比如新增可空字段、改默认值），且原生适配 Spark/Flink/Hadoop 生态。如果你的 pipeline 要跑在 Kafka + Flink 上，且上游 producer 可能随时加字段，Avro 比 Protobuf 更省心。
使用场景：日志采集上报、ETL 流转、需要长期存档且 schema 会缓慢变化的数据。
立即学习“Python免费学习笔记（深入）”；
常见错误现象：avro.schema.SchemaParseException: No schema type: null —— 实际是 JSON 格式 schema 字符串里漏写了 "type" 字段；或 Python 用 fastavro 读取时传入了字符串而非 avro.schema.Schema 对象。
- schema 必须随数据一起传输（或通过 Schema Registry），不能像 Protobuf 那样靠本地 .proto 文件隐式约定
- Python 中
fastavro不支持所有 Avro 类型（如logicalType: decimal需要额外配置decimal_bytes参数） - 没有官方 protoc 级别的代码生成，Python 端靠
fastavro.parse_schema()运行时加载，IDE 无法跳转字段，容易写错 key 名 - Avro 的 JSON 编码（用于调试）和二进制编码字段顺序一致，但 Protobuf 不保证顺序 —— 这点在做 diff 或 cache key 计算时容易踩坑
JSON 就是别硬上 Protobuf/Avro 的那个场景
当你需要人眼可读、浏览器直调、curl 调试、前端直接 JSON.parse()、或者接口只被内部脚本临时消费，JSON 不仅够用，而且更安全。强行替换成 Protobuf 反而增加构建复杂度、破坏可观测性、让 curl 测试变成不可能任务。
性能影响常被高估：Python 中 json.loads() 在多数中小 payload（ParseFromString() 快；真正瓶颈通常在 I/O 或业务逻辑，不在序列化本身。
- 字段缺失时
dict.get("xxx", default)比 Protobuf 的HasField("xxx")更直观，也比 Avro 的record.get("xxx")更少抛 KeyError - 不校验类型：
{"count": "123"}能过 JSON 解析，但 Protobuf 会报TypeError: 123 is not of type int（如果字段定义为int32） - 嵌套深、字段多时，JSON 的缩进+换行让排查问题快得多；Protobuf 二进制 dump 出来是乱码，Avro 至少还能用
fastavro.reader转成 dict 看一眼 - 别为了“统一”把 Flask 返回值全改成 Protobuf —— 浏览器打不开、Postman 看不见、Nginx access_log 记的全是乱码
选型卡住时，先问这三件事
很多纠结其实来自没厘清约束。与其查 benchmark，不如快速确认：
- 是否必须跨语言？如果只有 Python 内部模块通信，
pickle或msgpack可能更轻量（当然别存外部数据） - schema 会变吗？如果字段基本固定、半年一迭代，Protobuf 的强约束是优势；如果每周加字段、且下游消费者无法同步更新，Avro 的向后兼容机制才真正起作用
- 谁在读这个数据？如果是给人看、给 shell 脚本 parse、给 Grafana 当数据源，JSON 的普适性压倒一切
最容易被忽略的一点：Protobuf 和 Avro 都要求你管理 schema 生命周期，而 JSON 不需要。一旦开始用前两者，就得配套建 schema-registry、加 CI 校验、定版本发布流程 —— 这些成本，远比改几行序列化代码重得多。
