很遗憾，只有一个优点：易读。

你要知道，json 是一个起源于前端 javascript 的数据交换格式。javascript 中的 obj 对象，长这个样子：

{"name":"Alice","age":20}

json 就是直接照猫画虎直接这样设计出来的。

因为在此之前，都喜欢使用那个类似于 html 一样臃肿的 xml 来交换数据、传输数据。而 json 则看起来更好看、简洁、js 解释器能直接解读，而且人看起来也很容易看地明白。

最主要，还是易于人阅读。

恰逢在 2004 年，Ajax 点燃了 网站 大爆炸，json 一下子就被广泛使用，一举成名！

至此，它是几乎所有编程语言的默认的数据交换格式了。被所有编程语言接受。

但，则说明它好吗？(ÒܫÓױ)

它当然好，只是易于读而已。它的流行除了它太简单外，也是因为它没有专利保护。

除了易于人肉眼去阅读外，它其实没有任何优点了。

在后端里，我们更流行使用 Protobuf ，它不是什么新格式，它和 json 一样古老和成熟，诞生于 2001 年的谷歌公司，而且优点更多，（除了无法被直接阅读）。

其实我建议大家，多在项目里使用 Protobuf ！（调试的时候使用 json 可以，生产模式使用 Protobuf）

为啥呢？

 json 太灵活了，甚至过于灵活了，你可以随时添加字段、删除字段或更改类型，对于长期开发来说，这不一定是啥好事。

这意味啥？意味容易出错，你无法保证你发送的内容是清晰的！

你想想，每个 { ... } 里都是一段独立的数据，你没法保证 键 写正确了，或者 键 是那边的人需要的。

而且时间长了，业务复杂了，你里面缺少了、或者类型错了，往往会造成很多头疼的麻烦。

而你，我的朋友，Protobuf 就从根本上解决了这个问题！o(￣▽￣)ｄ

这个 Protobuf 是一个二进制的数据格式，人类不可读，在生成 .proto 之前，我们会先准备好它的结构。比如下面这个：

syntax = "proto3";  message User {   int32 id = 1;   string name = 2;   string email = 3;   bool isActive = 4; }

你看看你看看，每个字段（你可以理解为 json 里的 { ... } ）里，都跟写 C Java 一样，定义好了每个键的格式了！

• id 是 Int32

• name 是 字符串 string

• .....

后面是数字是字段编号，就是说在 .proto 里，不会出现 id 这个东西，只会出现 1。而 3 就是 email 了，Protobuf 不传字段名，它只传字段编号。以此保证传输体积小巧！

（当然，它不是类似于 Excel 这种电子表格，就是每个字段里的键个数不能变，它和 json 一样，是可选的，就是你的这个字段里面可以只放 id ，也可以什么都不放。）

在生成 .proto 的时候，无需手动验证。无需 JSON 解析。这个机制从根本上杜绝了类型错误风险。

它代表着巨大的时间节省，并带来了卓越的可维护性便利。

而且 Protobuf 是二进制的。不仅仅是二进制，它无文本键（它们被数字标签取代），它无空格，无 JSON 开销，甚至内部还有一些数据结构上的优化。

（二进制结构大概如此）

如果按照体积来算的话，根据长短大小不同，它会比 json 小 3~10 倍！甚至更多！

最终，性能和效率杠杠的！

是不是很诱人呢？

Protobuf 可以独立运行，适用于任何传统的 HTTP API。所有的主流编程语言都可以接受！而且非常成熟。

而且现在很多后端服务，尤其是谷歌公司内部，都是使用 Protobuf 的，用 json 不仅费钱，而且会显得 out 。

除了在阅读的时候有点障碍，但.... 生产环境下，谁天天读那传输的数据呢？考虑到 Protobuf 带来的极致的性能和效率优势，这种权衡是完全值得的。

阅读原文：原文链接