1樓：木木
提問非常引戰，json是主流，protobuf也有它的用武之地（對網路傳輸要求比較嚴格的地方，比如遊戲服務端），protobuf最大的優勢還不是它的序列與反序列化，而是傳輸效率高。但現在絕大部分場景是不需要在乎傳輸效率的，所以json無疑是最優秀的方案。
2樓：何志斌
歷史都是螺旋發展的，你們都很年輕，可能不知道ASN.1。PB這種概念早就有了，並不新鮮。JSON最大的好處是：人可讀。
所有東西都有適用場景，在夠用的情況下，越簡單越好。JSON真的很簡單，如果HTTP的body是JSON，對除錯是非常友好的。
3樓：
額是因為不懂。其實很多人並不知道在都使用當前主流的解析類庫的前提下 Json 比 pb 的處理效能差很多很多，但是很多人知道 Json 比 pb 使用起來方便很多很多，所以用 Json 的多。
4樓：JoJo
Protobuf的初衷是為了解決Google自己特定的工程問題，相較之下序列化後資料壓縮並不是它最初的主要目標。它的很多優點是需要在Google自己的infra下才能發揮巨大的優勢。它的使用也必須嚴格遵循特定規則才能保證它極高的後向相容和易於擴充套件性。
其他答案裡不少人的抱怨其實就是源於並未遵循這樣嚴格的標準產生的問題。
此外Protobuf最大的毛病還是開源支援並不完善，甚至至今也沒有官方開源的TS編譯器可用。
反過來JSON是Web標準，上手沒有任何門檻，資料內容傳輸的過程中可以隨便修改，內容可讀性高，開源支援廣泛，所以自然使用的人多了，應運而生各種複雜的問題也都有開源工具作為解決方案。
5樓：
因為絕大多數的開發並不需要解決太複雜的技術問題。
proto在傳輸上有效能優勢。這一點大家都講到其實不差這幾個bit，但是你肯定不能想想大規模的系統之間的rpc用的是json。
proto強定義了協議。這一點非常重要，能避免很多typo。有人說json可以做validation，你在客戶端也做麼？
而且這一點也讓proto成為乙個寫config不錯的語言。
proto也是一種非常好的儲存格式。如果你的開發需要做一些offline的分析，你就需要dump一些data。最簡單做乙個推薦系統，你需要把所有的training data存下來，這個也用json？
6樓：暗滅
兩邊生成輔助類，每個物件都要有，這是重不是輕。
好比是說，坐飛機比地鐵快，為什麼上下班大家不坐飛機呢？
所以pb通常用在解決對效能要求特別高的場景。
json被大量使用到原因就是易用性，pb是注重效能，兩者之間的選擇是乙個權衡。
易用性和效能和誇平台和成本都是考慮的因素，不然大家為嘛都不買房要租房呢。。
不說了我坐飛機從西直門到東直門去了。
7樓：xu ciro
用誰要先看場景，如果直接用tcp的情況，那肯定是用PB的，畢竟包頭要結構化了後面的正文用PB順理成章。而且這種後台通訊場景裡，技術棧複雜度低，雙方為了些效能上的提公升可以忍受一些不便，更容易達成協議。
如果用在HTTP場景下，硬要用PB就意思不大了，大前端、接入、後台、中臺、資料，各有各的套路，處理鏈路長這點優化帶來的提公升，比起來溝通和各個技術棧對PB相容的代價就微不足道了。
8樓：Tracy Liang
資訊密度，json比pb小那麼一點。
序列化，反序列化效能比json好一點。
json本身就是物件。跟弱型別的語言一樣，根本無需定義其結構，可擴充套件性好。
json基於文字，可讀性強，還能手寫。這點就強太多。
二進位制有大小端問題，浮點還有資料精度。文字只有有編碼問題。
gltf就是基於json設計的，需要使用二進位制時，指向外部檔案或者乙個資料塊就行。
正如程式語言可以分成，系統級語言，帶虛擬機器語言，指令碼弱型別語言。高效能跟靈活性本身就是矛盾的，就看適用場景。
9樓：西門吹牛
就目前大多數專案來說，還沒到需要摳 PB 對比Json 所帶來的效能優勢。
但是Json的遍歷性 ，可讀性、開發效率是PB 遠不足的。
10樓：RusTOS
在嵌入式這種需要高效率資料傳輸的場景裡pb也不是那麼理想。複雜度比tlv格式高很多，而且壓縮後也不具備十六進製制可讀性，效率也沒那麼高。
11樓：「已登出」
因為JSON是人容易閱讀的，這一條就足夠了，差那麼點效能算啥，大部分的web程式對效能其實不是那麼敏感，50毫秒和200毫秒的響應，正常人應該都感覺不出差異。pb在遊戲行業倒是用的非常多。
12樓：chunquedong
這個標題好氣人。Protocol Buffers叫「輕便」可能是對「輕便」這個詞有什麼誤解，Protocol buffers是我見過最重量級的東西了。
我的chunquedong/jsonc庫，專門為解決PB和JSON之爭而生。通過壓縮JSON格式，資料大小減半，解析速度快一倍，輕鬆轉為人類可讀的JSON。同時解決流量大小、速度、可debug性三大難題。。。
13樓：余浩
Json可讀性實在是太好了，在絕大部分場景下清晰易讀的資料報文都是程式設計師的福音
只有在特別大資料量以至於壓縮節省的那部分空間可以顯著的節省買記憶體和頻寬花的錢的時候 pb才會有明顯的優勢
14樓：
protocol buffer 的文件裡寫了1.pb處理結構化文字並沒有更大的優勢
2.json是自包含的，而pb不是，自包含的序列化方式理解和處理起來要簡單的多
理解乙個技術先從他的問題域著手，只有同乙個問題域下的不同技術，才會需要去PK效能，易用性之類的，才會有輸贏，否則，他們就都有存在的必要
15樓：馬秉堯
JSON 的用途有很多，不僅僅是用來傳輸資料。由於 JSON 格式簡單，可讀，便於手寫，所以它可以用來做配置檔案的格式。而 Protobuf 在這方面則沒有用武之地。
Protobuf 支援的語言有限，所以即使在跨語言通訊上，它也沒有什麼特別的優勢。比如 Thrift，Hprose 都是比使用它來做跨語言通訊更好的方案。
Protobuf 是二進位制資料的序列化，不便於除錯。它所儲存的資訊還沒有元資料資訊，因此，在沒有 schema 的情況下，也無法解碼，所以使用上不方便。另外，對於文字處理能力強，二進位制處理能力弱的語言來說，這種二進位制序列化在效能上不但沒有優勢，反而會成為劣勢。
從上面的分析來看，在任何方面 protobuf 都沒有什麼優勢。所以 protobuf 怎麼可能會取代 json 呢。
16樓：汪周洋
很多語言內建了json，例如python，js，php，所以不同語言之間互動用json挺方便，json可以直接用文字編輯器編輯，除了用做協議，很多還用做配置檔案，比如cocos2dx的UI布局檔案，protobuf的c++庫確實太大了，但是功能也強啊，pb除錯還是很好的，debug模式下，呼叫DebugString輕鬆打出json格式的日誌，比自己格式化輸出log要方便太多，另外這兩互相轉換還是挺方便的，看著用吧
17樓：趙北雲
1.序列化效能
2.逆序列化效能
3.壓縮比
4.開發難度
題主可根據這四項對比下pb、thrift、json、xml等其他應用層傳輸協議的區別
18樓：gh xu
說下各自的特點
pb速度快，體積小，效率高，功能強大，解析是太簡單。但是太重了，比如我只是從伺服器拉乙個更新資訊，用pb給服務端，客戶端都帶來不小的工作量。
json簡單，除錯方便，php天生支援，客戶端的開源庫小巧精悍。但是客戶端解析要小心點，不然容易crash。
差不多就這些了吧
19樓：
JSON是ECMA-404和RFC 7159定義的，protobuf是哪個標準委員會的？
--Protobuf序列化以後是二進位制的資料肉眼看不出資料內容
有哪些有哲理有深度有內涵的好句子？
好好生活 蓋世人讀書，第一要有志，第二要有識，第三要有恆。有志則斷不甘為下流 有識則知學問無盡，不敢以一得自足，如河伯之觀海，如井蛙之窺天，皆無識者也 有恆則斷無不成之事，此三者缺一不可。 我們是不是需要用謊言去打擊那些說謊的敵人？難道事實還不夠有力嗎？那麼，如果我們真的需要用謊言去打擊說謊的敵人，...
js有npm，rust有cargo，python有pip。C 有什麼？
phiysng 正是因為C 有悠久的歷史，所以它沒有乙個標準的包管理器。像Python和Rust都是更年輕的語言。C 有很多套機制可以做包管理，但是沒有乙個成為事實上的標準。我用過的可以進行包管理的有apt 系統包管理 vcpkg 微軟的 直接使用CMake做包管理和Canon。但是每乙個都只能解決...
有那些詩句有殺氣？
楚予微茫 俠客行 趙客縵胡纓 唐代 李白 趙客縵胡纓，吳鉤霜雪明。銀鞍照白馬，颯沓如流星。十步殺一人，千里不留行。事了拂衣去，深藏身與名。閒過信陵飲，脫劍膝前橫。將炙啖朱亥，持觴勸侯嬴。三杯吐然諾，五岳倒為輕。眼花耳熱後，意氣素霓生。救趙揮金錘，邯鄲先震驚。千秋二壯士，烜赫大樑城。縱死俠骨香，不慚世...