

## 🧐 为什么我们还在用 JSON？

JSON 是微服务通信的“老好人”——人见人爱，花见花开。它有三大优点：

- **人类可读**（程序员深夜 debug 时的救命稻草）
- **语言通吃**（Go、Python、JavaScript… 全都支持）
- **比 XML 简洁一万倍**（XML：我谢谢你全家）

但天下没有免费的午餐。JSON 的“可读性”恰恰是它的性能软肋——**每次接收数据，都得先 parse 成结构体**，这个过程既耗 CPU 又费内存。

比如在 Go 中：

```go
type Event struct {
    Type   string `json:"type"`
    Source string `json:"source"`
    // ...其他字段
}

var e Event
err := json.NewDecoder(r.Body).Decode(&e)
```

看似简单，背后却是一场“字符串到结构体”的翻译大会，效率嘛……你懂的。

---

## 🚀 方案升级：Protocol Buffers（Protobuf）

Google 出品，必属精品。Protobuf 是一种**二进制序列化协议**，主打一个“小、快、稳”。

### ✅ 优点：
- 比 JSON 更紧凑（体积小 30%~50% 很常见）
- 跨语言支持（Go、Java、Rust… 都行）
- 强类型 schema，减少运行时错误

### ❌ 缺点：
- 依然是“解析型”：收到数据后，还是要 `proto.Unmarshal` 成 Go 结构体
- 可读性差（一堆乱码，调试靠工具）

Go 示例：

```go
e := &events_pb.Event{}
err := proto.Unmarshal(data, e) // 依然要解析！
```

所以，Protobuf 虽快，但还没“快到飞起”。

---

## 🥷 终极选手：FlatBuffers

FlatBuffers 最初是 Google 为游戏开发搞出来的，目标就一个：**零解析、零内存分配、直接访问原始字节**！

### ✅ 核心优势：
- **无需 Unmarshal**！数据在内存中就是“就绪状态”
- **零拷贝访问**：直接通过偏移量读字段
- 同样是二进制，但比 Protobuf 更激进

Go 中怎么用？

```go
e := events.GetRootAsEvent(data, 0) // 直接拿到“指针式”对象
saveEvent(string(e.Type()), string(e.Source()), ...)
```

注意：这里 `e.Type()` 返回的是 `[]byte`，转成 `string` 才能用——但整个过程**没有 new struct，没有 deep copy**！

---

## 📊 性能实测：Go 基准测试结果

作者搭建了一个简单的事件上报 API，分别用 JSON、Protobuf、FlatBuffers 实现，然后跑 Go benchmark：

| 格式          | 每次操作耗时 (ns/op) | 内存分配 (B/op) | 分配次数 (allocs/op) |
|---------------|---------------------|------------------|----------------------|
| JSON          | 1732                | 2288             | 26                   |
| Protobuf      | 697                 | 1952             | 21                   |
| **FlatBuffers** | **640**             | **1856**         | **21**               |

> 💡 **结论**：  
> - FlatBuffers 比 JSON 快 **2.7 倍**！  
> - 内存也更省，尤其在高并发场景下，GC 压力显著降低。





---

## 🤔 那我该用哪个？

| 场景 | 推荐方案 |
|------|--------|
| 内部 API、低频调用、快速开发 | ✅ JSON（简单、直观、调试方便） |
| 高性能 RPC、gRPC 生态 | ✅ Protobuf（生态成熟，工具链完善） |
| 极致性能、高频事件、低延迟要求（如游戏、IoT、审计日志） | ✅✅ **FlatBuffers** |

> 🧠 **记住**：不要为了“快”而盲目替换。  
> 如果你的服务每天只有 1000 个请求，用 FlatBuffers 可能反而增加维护成本。  
> 但如果你每天处理 **10 亿事件**，那省下的服务器费用可能够你买辆特斯拉了 🚗。

---

## 🔧 小贴士：如何开始？

1. **定义 schema**  
   - Protobuf: `event.proto`
   - FlatBuffers: `event.fbs`

2. **生成 Go 代码**
   ```bash
   # Protobuf
   protoc --go_out=. event.proto

   # FlatBuffers
   flatc --go event.fbs
   ```

3. **集成到 HTTP handler**

---

## 🎉 结语

JSON 是“舒适区”，Protobuf 是“性能升级包”，而 FlatBuffers 是“性能外挂”。  
选择哪个，取决于你的业务需求、团队能力和性能瓶颈。

> **技术不是越新越好，而是越合适越好**。  
> 但了解这些选项，能让你在关键时刻，多一张王牌。

---



但天下没有免费的午餐。JSON 的“可读性”恰恰是它的性能软肋——每次接收数据，都得先 parse 成结构体，这个过程既耗 CPU 又费内存。

JSON vs Protocol Buffers vs FlatBuffers：谁才是高性能序列化的“卷王”？

后端

编程语言

算法

JSON、Protobuf和FlatBuffers是三种主流数据交换格式。JSON易读但性能较差，Protobuf体积小速度快，FlatBuffers实现零解析直接访问。实测FlatBuffers比JSON快2.7倍，内存更省。根据业务场景选择：JSON适合快速开发，Protobuf适合RPC，FlatBuffers适合高性能场景。合理选择能显著提升系统性能。

游戏开发

服务器

Python

JSON

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

JSON、Protobuf和FlatBuffers是三种主流数据交换格式。JSON易读但性能较差，Protobuf体积小速度快，FlatBuffers实现零解析直接访问。实测FlatBuffers比JSON快2.7倍，内存更省。根据业务场景选择：JSON适合快速开发，Protobuf适合RPC，FlatBuffers适...

JSON vs Protocol Buffers vs FlatBuffers：谁才是高性能序列化的“卷王”？-腾讯云开发者社区-腾讯云

JSON vs Protocol Buffers vs FlatBuffers：谁才是高性能序列化的“卷王”？

JSON vs Protocol Buffers vs FlatBuffers：谁才是高性能序列化的“卷王”？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐