假設，但不是憑空想象，在你的程序中，你注冊了一堆 expvar 包的統計變量[1]，用來在暴露出去的 JSON 結果中能有一個容易辨識的名字。普通的實現方式下，你可能會有一大堆全局變量，對應著程序追蹤的各種信息。這些變量與其他的全局變量混成一團，這毫無美感，如果我們能規避這種情況，那么事情會變得不那么糟糕。

[[334282]]

歸功于 Go 對匿名結構類型的支持，我們可以實現。我們可以基于匿名結構類型創建一個變量集合的命名空間：

var events struct { 
    connections, messages [expvar.Int](expvar.Int "expvar.Int") 
 
    tlsconns, tlserrors [expvar.Int](expvar.Int "expvar.Int") 
} 

在我們的代碼中，我們可以使用 events.connects 等等，而不是必須用一些很糟糕或容易引起歧義的名字。

我們也可以在全局等級范圍外用這種方法。你可以在這種命名空間結構內把任意的變量名集合隔離開。一個例子就是把計數變量嵌入到另一個結構體中：

type ipMap struct { 
    sync.Mutex 
    ips map[string]int 
    stat struct { 
        Size, Adds, Lookups, Dels int 
    } 
} 

type ipMap struct { 
    sync.Mutex 
    ips map[string]int 
    stat struct { 
        Size, Adds, Lookups, Dels int 
    } 
} 

原因很明顯，這對于不需要進行初始化的變量類型是最好的解決方案;其他的變量類型需要進行一些初始化，這稍微有一點點笨重。

這可能不合某些人的口味，我也不知道這在 Go 中是不是好的做法。我的個人觀點是，我與其用前綴 prefix_ 來隔離變量名，不如用前綴 prefix. ，盡管人為地引入了這樣的匿名結構體。但是一些人可能會有不同看法。即使在我看來，它也確實是侵入較大的修改，但可能它是合法的。

(為了更加明確地統計計數信息，這也是一種方便地暴露所有信息的方法[2])

出于好奇我快速瀏覽了當前開發中的 Go 編譯器和標準庫，隱約在幾處地方發現了疑似使用這種方式的地方。并不是所有的使用方式都一樣，所以看了源碼后我要說的重點是，這似乎也不是一種完全不可容忍或被原作者反對的觀點。