相信大部分的開發朋友現在日常中用到的基本都是數據傳輸格式基本都是 JSON 格式，其好處在於通用性且可讀性強、易理解，相對於 javascript 來說 JSON 看上去感官上基本就是一個 對象多加些引號罷了非常親切。
但是實際生產中並不是每一中情況都需要我們提供高通用、高易讀性的數據傳輸，例如我們在進行一些實時數據傳輸過程中往往速度才是真理，這種情況下我們可能就會覺得 json 的數據量是不是有點大？是不是可以減小點傳輸體積？結構和含義可以文檔搞定啊。
還有場景就是加密傳輸，這種場景也是不能直接使用 JSON 文本的，通常就是將我們的數據經過加密算法處理后得到一個新的數據（通常是字符串，為什么是通常這里不做闡述），但是現在我們通常前后端加密通訊基本都是加密算法+JSON，通過對 JSON 進行加密處理后進行傳輸，也可能是加密后的數據仍放在一個 JSON 中，單無論如何加密算法通常都是增加體積的，越是級別高的加密方式增加的體積量一定維度上來說是越高的，所以可以考慮給加密前的數據進行一個 “壓縮” 處理，可以是實用壓縮算法也可以是更換一個數據量更小的數據格式。
綜上而言，我們最好需要知道一些更加高效的數據傳輸格式或具有制定高效的數據格式的能力，最后選擇哪種方案取決於你的實際場景了，這里簡述一些選用思路
主要的三種方式：
1. 自定義二進制（適用於擁有自制定規范能力的人群，需要對於計算機中數據存儲與二進制的相關知識充足）
2. 使用一些已有的序列化與反序列化的協議（可以是開源可以是商用性的，取決於公司決策吧，為啥協議會有商用性的？萬一人家申請了專利呢）或者簡單數據結構通過自定義解析方案來做序列化反序列化
3. 使用現有的通用協議 JSON/XML 等（這些標准協議很多語言都通用並提供了語言層面或框架層面的序列化與反序列化的方案，屬於開箱即用，學習成本極低）
對於 1 來說，如果你有協議編程經歷，那么對你來說並沒有什么難度，只需要根據實際場景來合理運用即可；對於沒有先關經歷的人來說最好需要扎實下位運算、數據存儲，了解下 HTTP 傳輸過程中的各層協議的處理方式后再思考自己的方案。
對於 2 來說，你只需要選擇一個前后端具有相同的協議規范的工具，然后根據文檔來就行了。
對於 3 來說，這個我不需要說啥的了。
個人思考的各種方式推薦的協議推薦方向
方式 1
1. 參考 HTTP 各層協議的處理方式，即使用類似協議頭方式來決定處理規則，對於像 JSON 這類原本就是嵌套的數據結構可以做較好的一個轉換
2. 參考密碼學中的一些思路，將固定字節位作為標示識別位，其他字節位作為數據位用於存放數據
方式 2
1. MessagePack（現有的一個自定義的方案）。
2. 數組，通常用於操作指令，自定義每個下標的內容的含義，需要自己梳理文檔。
3. 字符串，與上面方式 1 的思考一致，不過這里不是用字節位，而是字符位，需要注意的是對於處理字符串需要明確編碼格式，否則某些情況可能會出問題。同樣需要自己梳理詳細文檔，理解成都上不及數組形式。該方式也適用於自定義的弱加密，其優勢在於可以自定義，只需要自己編寫並更新 sdk 或 npm 包即可實現一個弱雞版更新算法的功能，推薦實用短緩存的 sdk 形式（js 中即為 script 中引入而非 npm 包）。
方式 3
1. XML
a. 易讀性還可以，其可擴展性和嚴格的標簽格式使其在配置文件中得到生存。
b. 由於其數據讀取的麻煩已經被 JSON 在數據傳輸領域基本干掉了。
2. YAML
a. 由於實現簡單，解析成本低，特別適合在腳本語言中使用。
b. YAML比較適合做序列化。因為它是宿主語言數據類型直轉的，但跨語言支持沒有得到多大支持，且易讀性上也並不勝於 JSON。
c. 但和 JSON 對比顯然 JSON 更得前端開發者的心。
3. JSON
a. 具有自我描述性，易於閱讀編寫，也易於機器解析與生成
b. 使用 Javascript語法來描述數據對象，但是 JSON 仍然獨立於語言和平台。JSON 解析器和 JSON 庫支持許多不同的編程語言，語言支持度極好。
4. Blob
a. 一般上傳文件、canvas、webAudio 中用到，主要用於對文件的操作（Blob 表示一個不可變的、原始數據的類文件對象）。
5. Buffer 等等不做闡述
無特殊需求前端不用選，自然是 JSON 了。如有特殊的傳輸需求或加密場景才需要考慮其他方式，如果沒有的話就不要整那些花里胡哨的東西了，自己可以玩玩作為沉淀，但是生產需謹慎而行。
如果你有補充或想糾正的地方，歡迎在評論區指出。謝謝！