Go 語言是靜態(tài)類型語言，雖然它也可以表現(xiàn)出動(dòng)態(tài)類型，但是使用一個(gè)嵌套的 map[string]interface{} 在那里亂叫會(huì)讓代碼變得特別丑。通過掌握語言的靜態(tài)特性，我們可以做的更好。

通過同一通道交換多種信息的時(shí)候，我們經(jīng)常需要 JSON 具有動(dòng)態(tài)的，或者更合適的參數(shù)內(nèi)容。首先，讓我們來討論一下消息封裝(message envelopes)，JSON 在這里看起來就像這樣：

{
 "type": "this part tells you how to interpret the message",
 "msg": ...the actual message is here, in some kind of json...
}

通過不同的消息類型生成 JSON

通過 interface{}，我們可以很容易的將數(shù)據(jù)結(jié)構(gòu)編碼成為獨(dú)立封裝的，具有多種類型的消息體的 JSON 數(shù)據(jù)。為了生成下面的 JSON ：

{
 "type": "sound",
 "msg": {
 "description": "dynamite",
 "authority": "the Bruce Dickinson"
 }
}
{
 "type": "cowbell",
 "msg": {
 "more": true
 }
}

我們可以使用這些 Go 類型：

輸出的結(jié)果是：

{"Type":"sound","Msg":{"Description":"dynamite","Authority":"the Bruce Dickinson"}}
{"Type":"cowbell","Msg":{"More":true}}

這些并沒有什么特殊的。

解析 JSON 到動(dòng)態(tài)類型

如果你想將上面的 JSON 對(duì)象解析成為一個(gè) Envelope 類型的對(duì)象，最終你會(huì)將 Msg 字段解析成為一個(gè) map[string]interface{}。 這種方式不是很好用，會(huì)使你后悔你的選擇。

輸出：

dynamite

明確的解析方式

就像前面說的，我推薦修改 Envelope 類型，就像這樣：

type Envelope {
 Type string
 Msg *json.RawMessage
}

json.RawMessage 非常有用，它可以讓你延遲解析相應(yīng)的 JSON 數(shù)據(jù)。它會(huì)將未處理的數(shù)據(jù)存儲(chǔ)為 []byte。

這種方式可以讓你顯式控制 Msg 的解析。從而延遲到獲取到 Type 的值之后，依據(jù) Type 的值進(jìn)行解析。這種方式不好的地方在于你需要先明確解析 Msg，或者你需要單獨(dú)分為 EnvelopeIn 和 EnvelopeOut 兩種類型，其中 EnvelopeOut 仍然有 Msg interface{}。

結(jié)合 *json.RawMessage 和 interface{} 的優(yōu)點(diǎn)

那么如何將上述兩者好的一面結(jié)合起來呢？通過在 interface{} 字段中放入 *json.RawMessage!

輸出：

dynamite

如何把所有數(shù)據(jù)都放在最外層（頂層）

雖然我極其推薦你將動(dòng)態(tài)可變的部分放在一個(gè)單獨(dú)的 key 下面，但是有時(shí)你可能需要處理一些預(yù)先存在的數(shù)據(jù)，它們并沒有用這樣的方式進(jìn)行格式化。

如果可以的話，請(qǐng)使用文章前面提到的風(fēng)格。

{
 "type": "this part tells you how to interpret the message",
 ...the actual message is here, as multiple keys...
}

我們可以通過解析兩次數(shù)據(jù)的方式來解決。

dynamite

via: http://eagain.net/articles/go-dynamic-json/

作者：Tommi Virtanen 譯者：jliu666 校對(duì)：polaris1119

本文由 GCTT 原創(chuàng)編譯，Go語言中文網(wǎng) 榮譽(yù)推出