golang什麼時候應該把方法綁定在struct的值上而不是指標上？

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

golang 支援 struct 也支援 struct 的指標。一個常見的困惑是既然struct 指標存在了，為什麼不乾脆只有struct的指標呢？兩個原因：

• struct不可空，而struct指標可以為nil

• []my_struct的記憶體是連續的，而[]*my_struct只有指標是連續存放的，而實際的內容則需要跟隨指標去讀取

同時struct應該也有助於escape analysis，使得對象可以分配在棧上，而不用去進行多線程爭搶的分配堆上的記憶體。但是這隻是一個猜想。

一個更有趣的問題是，什麼時候方法應該綁定在struct上，而不是struct指標上？考慮以下測試程式

type MyStruct struct {    field int}

local_variable := MyStruct{1}fmt.Println(unsafe.Pointer(&local_variable))local_variable.modify_struct_value()fmt.Println(local_variable) // {1}copied := local_variable.copy_my_self()fmt.Println(unsafe.Pointer(&copied))

func (self MyStruct) modify_struct_value() {    fmt.Println(unsafe.Pointer(&self))    self.field = 2}func (self MyStruct) copy_my_self() MyStruct {    fmt.Println(unsafe.Pointer(&self))    return self}

執行的輸出是

0xc82000a2c80xc82000a2e0{1}0xc82002a0280xc82000a2f0

這個證明了幾個事情

• 在方法執行之前struct就被拷貝了一份

• 對這份拷貝的修改，不會影響原struct（廢話）

• 如果返回這份拷貝給調用方，調用方在儲存在局部變數的時候還會再拷貝一遍（沒有return value optimization）

根據這樣的行為，除非我們想讓一個方法是類似c++的const的行為（以記憶體拷貝為代價），其他的情境下基本沒有理由把行為綁定在struct上而不是綁定在struct指標上。

結論：

• struct因為可以控制記憶體layout，有其存在意義。效能不敏感的情境，一直使用struct指標也無需有負罪感。

• 總是把方法綁定在struct指標上，而不要綁定在struct上，以避免不必要的記憶體拷貝