Protobuf 通常比 XML 快得多，序列化和反序列化耗时一般只有 XML 的 1/5 到 1/10，体积也普遍小 3–10 倍。核心差异不在“语法”，而在设计哲学：XML 是面向人可读的通用标记语言，Protobuf 是面向机器高效通信的二进制接口定义语言。
序列化体积差异明显
XML 包含大量重复标签、空格、引号和自描述字段名，即使启用压缩（如 gzip），原始体积仍远大于 Protobuf 的二进制编码。Protobuf 使用字段编号+变长整数（Varint）、无分隔符、不存字段名、支持 packed 编码等机制极致压缩数据。
- 一个含 10 个整数的简单列表：XML 可能占 200+ 字节（含标签和换行），Protobuf 通常低于 30 字节
- 嵌套结构中，XML 每层都重复开闭标签；Protobuf 仅靠字段编号和长度前缀定位，无冗余文本
- Protobuf 不传输默认值（如 int32 字段为 0），XML 即使是默认值也必须显式写出
解析速度差距主要来自解析模型
XML 需完整词法分析（识别标签、属性、实体、CDATA 等）+ 语法分析（构建 DOM 树或事件驱动 SAX），而 Protobuf 解析是纯二进制流扫描：按预编译 schema 顺序读取字段编号→跳过未知字段→用 Varint/固定长度规则直接解出值，无字符串匹配、无内存分配开销（尤其在 C++/Rust 中可零拷贝）。
- DOM 解析 XML 需构建完整树形结构，内存占用高、GC 压力大；Protobuf 解析通常直接填充目标对象字段
- 即使是轻量级的 SAX 或 StAX，仍需状态机维护标签栈；Protobuf 解析逻辑接近 memcpy + 位移计算
- Protobuf 的 .proto schema 在编译期固化，运行时无需反射或动态类型推断
适用场景不能只看性能数字
XML 在需要人类可读性、浏览器原生支持、与现有系统（如 SOAP、RSS、配置文件）集成、或需 XPath/XSLT 处理时仍有不可替代性。Protobuf 强依赖生成代码和严格 schema，适合内部微服务通信、移动端 API、日志采集等对带宽和延迟敏感的场景。
- 调试时，直接 cat 一个 XML 文件能快速定位问题；Protobuf 二进制需用 protoc --decode 查看
- Web 前端天然支持 XML（XMLHttpRequest、DOMParser），但需额外库（如 protobuf.js）处理 Protobuf
- XML 支持注释、命名空间、文档类型定义（DTD）等扩展能力，Protobuf 专注数据结构契约，不提供这些语义
真实优化建议
别只比“裸测吞吐量”。实际性能受网络、语言绑定、内存管理、是否启用 streaming、schema 设计（如 repeated 字段是否用 packed）影响更大。建议：
- 用真实业务 payload 做压测，而非 toy schema；关注 P99 延迟而非平均值
- Protobuf 升级到 v3 并启用 lite runtime（尤其 Android）；XML 优先选 StAX 而非 DOM
- 若需兼顾人读和机器效，可考虑 JSON（比 XML 轻，比 Protobuf 易读），再通过 gRPC-JSON 转换桥接
