本文通过标准化基准测试揭示 go 标准库中 json、gob 和 xml 三种序列化格式在性能（吞吐量）与体积（序列化后大小）上的真实差异：gob 最快最小，json 次之且兼顾可读性与兼容性，xml 则显著更慢更大，不推荐用于高性能内部通信。
本文通过标准化基准测试揭示 go 标准库中 json、gob 和 xml 三种序列化格式在性能（吞吐量）与体积（序列化后大小）上的真实差异：gob 最快最小，json 次之且兼顾可读性与兼容性，xml 则显著更慢更大，不推荐用于高性能内部通信。
在 Go 应用开发中，选择合适的序列化格式直接影响系统吞吐量、内存占用与网络带宽消耗。根据实证基准测试（基于稳定 CPU 频率、内存内序列化、固定数据规模），三者性能排序明确且具有一致性：
✅ GOB：Go 原生二进制格式，专为 Go 类型设计
- ✅ 性能最优：平均序列化耗时约 230 μs（仅为 JSON 的 ~40%，XML 的 ~1/10）
- ✅ 体积最小：约 9.07 KB（比 JSON 小 ~52%，比 XML 小 ~65%）
- ⚠️ 局限：仅限 Go 生态互操作，不跨语言，无可读性，结构变更需谨慎处理版本兼容
✅ JSON：文本格式，通用性强
- ✅ 平衡表现：序列化耗时约 599 μs，体积约 18.78 KB
- ✅ 优势：人类可读、Web 友好、跨语言支持完善、调试友好
- ⚠️ 注意：encoding/json 默认使用反射，对结构体字段名做 json:"name" 映射会引入少量开销；启用 jsoniter 或预编译 easyjson 可提升 2–3 倍性能（但增加构建复杂度）
❌ XML：冗余度高，性能最弱
- ❌ 耗时最高：约 2404 μs（是 JSON 的 4 倍、GOB 的 10 倍）
- ❌ 体积最大：约 25.78 KB（比 JSON 大 ~37%，比 GOB 大 ~185%）
- ⚠️ 原因：标签闭合、命名空间、属性语法等固有冗余；Go 的 encoding/xml 解析器需频繁字符串匹配与状态机跳转，CPU 缓存不友好
以下为轻量级、可复现的基准对比示例（内存内序列化，规避 I/O 波动）：
func BenchmarkJSON(b *testing.B) {
data := generateTestData(1000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
_ = json.Marshal(data)
}
}
func BenchmarkGOB(b *testing.B) {
data := generateTestData(1000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
var buf bytes.Buffer
enc := gob.NewEncoder(&buf)
_ = enc.Encode(data)
}
}
func BenchmarkXML(b *testing.B) {
data := generateTestData(1000)
b.ResetTimer()
for i := 0; i < b.N; i++ {
_ = xml.Marshal(data)
}
}? 关键实践建议：
- ? 微服务/进程间通信（同构 Go 系统）→ 优先选 GOB（或更现代的 Protocol Buffers + gRPC）
- ? API 对外暴露、配置文件、日志输出 → 必选 JSON（配合 json.RawMessage 或 omitempty 控制体积）
- ? 遗留系统集成或特定行业标准（如 SOAP）→ 谨慎使用 XML，并务必缓存解析结果、避免高频重复 Marshal/Unmarshal
- ? 性能敏感场景：禁用 CPU Turbo Boost、绑定固定核心运行基准；避免首次运行冷启动干扰（go test -bench . -benchmem -count=5 取中位数）
综上，性能不是唯一维度——GOB 胜在效率，JSON 赢在生态，XML 仅适用于合规性刚需。合理选型，方能兼顾开发效率与运行时表现。
