Go語言本來就以輕量快速著稱，一位GitHub員工卻偶然發現：

只改變一個字符的位置，能把一段代碼運行速度提高足足42%。

簡直就像是……

這個簡單有效的技巧一經發布，就引來眾多程序員圍觀。

原作者自己也調侃，一般這種情況都是事先犯了個愚蠢的錯誤，后面才能提升這么大。

不過順著這個思路發現有人發現，就連Go開發團隊的核心人物Russ Cox都在標準庫中犯過同樣的錯誤。

什么樣的錯誤？

發現這個問題的Harry在大型程序員交友平臺GitHub工作。

他在開發一個把GitHub倉庫中每個文件的所有者列出來的小工具。

功能很簡單，就是根據CODEOWNERS文件中定義的規則匹配，寫在越下面的規則優先級越高。

原理也很簡單，就是從后往前一條一條處理，匹配到了就停止。

但就是這樣一個簡單的程序卻出現了性能問題，處理中等大小的倉庫就很慢了。

他打印出火焰圖，發現大部分時間都花在了Go語言的正則表達式引擎中。

另外在內存動態分配malloc和垃圾回收gc上面的花費也值得注意。

要減少malloc的時間，就需要用到Go語言的逃逸分析（Escape Analysis）了。

簡單來說，就是盡量把變量分配到棧上，讓編譯器自動管理內存的釋放。

只有在“逃逸”也就是變量的作用域超出所在的棧時，才把變量分配到堆上，減輕運行時GC的壓力。

在這次的程序中，Harry確定了逃逸的變量是rule這個結構體(struct)。

但問題是，rule存儲在RuleSet這個切片(slice)里，按Go語言的規則可以確信他已經在堆中了。

再分析一下代碼，發現在給rule賦值的時候實際上是做了一次不必要的拷貝，后面用“&”取地址時候創建了一個逃逸的指針指向它的副本。

最后解決辦法也很容易想出，只需要把&移動到上面。

這樣就引用了切片中的結構體，避免了拷貝。

如何徹底避免？

在熱議中，有網友分享了自己是怎么避免出現這個問題的。

對于每個結構體，把它看作純值或純指針，壓根就不去使用&這種取地址的操作，避免隱式的內存分配。

如果你想要深入理解這個問題，也有人貼心的給出了需要提前了解的一些背景知識。

最后有人指出，Rust語言為避免這個問題，直接規定必須顯式操作才能拷貝一個數據結構。

當你不習慣的時候這規定煩得要命，但是總的來看還是值得。

方便or規范，你更傾向于哪種做法？

審核編輯 ：李倩