12.5. 通過reflect.Value修改值

到目前為止，反射還只是程序中變量的另一種讀取方式。然而，在本節中我們將重點討論如何通過反射機制來修改變量。

回想一下，Go語言中類似x、x.f[1]和*p形式的表達式都可以表示變量，但是其它如x + 1和f(2)則不是變量。一個變量就是一個可尋址的內存空間，裡面存儲了一個值，並且存儲的值可以通過內存地址來更新。

對於reflect.Values也有類似的區別。有一些reflect.Values是可取地址的；其它一些則不可以。考慮以下的聲明語句：

x := 2                   // value   type    variable?
a := reflect.ValueOf(2)  // 2       int     no
b := reflect.ValueOf(x)  // 2       int     no
c := reflect.ValueOf(&x) // &x      *int    no
d := c.Elem()            // 2       int     yes (x)

其中a對應的變量不可取地址。因為a中的值僅僅是整數2的拷貝副本。b中的值也同樣不可取地址。c中的值還是不可取地址，它只是一個指針&x的拷貝。實際上，所有通過reflect.ValueOf(x)返回的reflect.Value都是不可取地址的。但是對於d，它是c的解引用方式生成的，指向另一個變量，因此是可取地址的。我們可以通過調用reflect.ValueOf(&x).Elem()，來獲取任意變量x對應的可取地址的Value。

我們可以通過調用reflect.Value的CanAddr方法來判斷其是否可以被取地址：

fmt.Println(a.CanAddr()) // "false"
fmt.Println(b.CanAddr()) // "false"
fmt.Println(c.CanAddr()) // "false"
fmt.Println(d.CanAddr()) // "true"

每當我們通過指針間接地獲取的reflect.Value都是可取地址的，即使開始的是一個不可取地址的Value。在反射機制中，所有關於是否支持取地址的規則都是類似的。例如，slice的索引表達式e[i]將隱式地包含一個指針，它就是可取地址的，即使開始的e表達式不支持也沒有關係。以此類推，reflect.ValueOf(e).Index(i)對應的值也是可取地址的，即使原始的reflect.ValueOf(e)不支持也沒有關係。

要從變量對應的可取地址的reflect.Value來訪問變量需要三個步驟。第一步是調用Addr()方法，它返回一個Value，裡面保存了指向變量的指針。然後是在Value上調用Interface()方法，也就是返回一個interface{}，裡面包含指向變量的指針。最後，如果我們知道變量的類型，我們可以使用類型的斷言機制將得到的interface{}類型的接口強制轉為普通的類型指針。這樣我們就可以通過這個普通指針來更新變量了：

x := 2
d := reflect.ValueOf(&x).Elem()   // d refers to the variable x
px := d.Addr().Interface().(*int) // px := &x
*px = 3                           // x = 3
fmt.Println(x)                    // "3"

或者，不使用指針，而是通過調用可取地址的reflect.Value的reflect.Value.Set方法來更新對應的值：

d.Set(reflect.ValueOf(4))
fmt.Println(x) // "4"

Set方法將在運行時執行和編譯時進行類似的可賦值性約束的檢查。以上代碼，變量和值都是int類型，但是如果變量是int64類型，那麼程序將拋出一個panic異常，所以關鍵問題是要確保改類型的變量可以接受對應的值：

d.Set(reflect.ValueOf(int64(5))) // panic: int64 is not assignable to int

同樣，對一個不可取地址的reflect.Value調用Set方法也會導致panic異常：

x := 2
b := reflect.ValueOf(x)
b.Set(reflect.ValueOf(3)) // panic: Set using unaddressable value

這裡有很多用於基本數據類型的Set方法：SetInt、SetUint、SetString和SetFloat等。

d := reflect.ValueOf(&x).Elem()
d.SetInt(3)
fmt.Println(x) // "3"

從某種程度上說，這些Set方法總是儘可能地完成任務。以SetInt為例，只要變量是某種類型的有符號整數就可以工作，即使是一些命名的類型、甚至只要底層數據類型是有符號整數就可以，而且如果對於變量類型值太大的話會被自動截斷。但需要謹慎的是：對於一個引用interface{}類型的reflect.Value調用SetInt會導致panic異常，即使那個interface{}變量對於整數類型也不行。

x := 1
rx := reflect.ValueOf(&x).Elem()
rx.SetInt(2)                     // OK, x = 2
rx.Set(reflect.ValueOf(3))       // OK, x = 3
rx.SetString("hello")            // panic: string is not assignable to int
rx.Set(reflect.ValueOf("hello")) // panic: string is not assignable to int

var y interface{}
ry := reflect.ValueOf(&y).Elem()
ry.SetInt(2)                     // panic: SetInt called on interface Value
ry.Set(reflect.ValueOf(3))       // OK, y = int(3)
ry.SetString("hello")            // panic: SetString called on interface Value
ry.Set(reflect.ValueOf("hello")) // OK, y = "hello"

當我們用Display顯示os.Stdout結構時，我們發現反射可以越過Go語言的導出規則的限制讀取結構體中未導出的成員，比如在類Unix系統上os.File結構體中的fd int成員。然而，利用反射機制並不能修改這些未導出的成員：

stdout := reflect.ValueOf(os.Stdout).Elem() // *os.Stdout, an os.File var
fmt.Println(stdout.Type())                  // "os.File"
fd := stdout.FieldByName("fd")
fmt.Println(fd.Int()) // "1"
fd.SetInt(2)          // panic: unexported field

一個可取地址的reflect.Value會記錄一個結構體成員是否是未導出成員，如果是的話則拒絕修改操作。因此，CanAddr方法並不能正確反映一個變量是否是可以被修改的。另一個相關的方法CanSet是用於檢查對應的reflect.Value是否是可取地址並可被修改的：

fmt.Println(fd.CanAddr(), fd.CanSet()) // "true false"