Go 1.1 相比 Go1.0 有哪些值得注意的改動？
Go 1.1 值得關注的改動：
- 字符串和 rune 字面量的定義被細化，明確排除了 Unicode 代理對（surrogate halves）作為有效的 Unicode 碼點。這確保了 Go 在處理 Unicode 字符時更加符合標準。
- Go 1.1 實現了 方法值（method values），這是一種綁定到特定接收器實例的函數。它與 方法表達式（method expressions）不同，后者是基于類型生成函數。這個改動是向后兼容的。
- 在 64 位平臺上，int 和 uint 類型的大小從 32 位調整為 64 位。這使得在 64 位系統上可以分配超過 20 億個元素的切片，但也可能影響依賴 int 為 32 位假設的代碼行為。
- 在 64 位架構上，最大堆內存（heap）大小顯著增加，從之前的幾 GB 提升到了數十 GB，具體取決于系統。32 位架構的堆大小保持不變。
- 引入了一個重要工具：競態檢測器（race detector）。它可以幫助發現并發訪問同一變量（且至少一個是寫操作）導致的 bug，通過 go test -race 等命令啟用。
- go 命令進行了一些改進以優化新用戶體驗，包括在找不到包時提供更詳細的錯誤信息（包含搜索路徑），以及 go get 命令強制要求設置有效的 $GOPATH。
- go test 命令在啟用性能分析時不再刪除測試二進制文件，方便進行后續分析。同時，新增了阻塞分析（blocking profile）功能 (-blockprofile)，用于報告 goroutine 的阻塞點。
- bufio 包新增了 Scanner 類型，提供了一種更簡單、更常用的方式來讀取文本輸入，例如按行或按空格分隔的單詞讀取。對于簡單場景，它比之前的 ReadBytes, ReadString 等函數更方便。
下面是一些值得展開的討論：
Unicode 代理對的處理調整
Go 1.1 對 Unicode 字符的處理進行了更嚴格的約束，特別是禁止了 代理對（surrogate halves）作為獨立的 rune 值。代理對是 Unicode 標準中為了在 UTF-16 編碼里表示超過 65535 的碼點而設計的特殊范圍，它們本身不代表任何字符，只能成對出現用于組合。
在 Go 1.1 中，編譯器、庫和運行時都強制執行了這一約束：一個獨立的代理對碼點被視為非法的 rune 值，無論是在 UTF-8 編碼中，還是在單獨的 UTF-16 編碼中。當遇到這類非法值時（例如，從 rune 轉換為 UTF-8），它會被視為編碼錯誤，并產生 Unicode 替換字符 utf8.RuneError (U+FFFD)。
例如，以下代碼在 Go 1.0 和 Go 1.1 中的行為不同：
package main
import "fmt"
func main() {
// 0xD800 是一個高位代理項（high surrogate）
fmt.Printf("%+q\n", string(0xD800))
}在 Go 1.0 中，它會打印 "\ud800"。但在 Go 1.1 中，由于 0xD800 是一個非法的獨立 rune 值，它會被替換字符替代，打印 "\ufffd"。
相應地，包含代理對 Unicode 值的 rune 和 string 常量現在也是非法的，例如 '\ud800' 或 "\ud800" 會導致編譯錯誤。
package main
func main() {
// Go 1.1 中編譯錯誤: illegal rune literal
// const r = '\ud800' // 注意是單引號
// Go 1.1 中編譯錯誤: illegal rune literal
// const s = "\ud800" // 注意是雙引號
}不過，如果開發者顯式地使用其 UTF-8 字節序列來創建字符串，例如 "\xed\xa0\x80"（這是 U+D800 的 UTF-8 編碼），這種字符串仍然可以被創建。但是，當嘗試將這種包含非法 UTF-8 序列的字符串解碼為 rune 序列時（例如在 range 循環中），只會得到 utf8.RuneError。
package main
import "fmt"
func main() {
// U+D800 的 UTF-8 編碼是 ED A0 80
s := "\xed\xa0\x80"
fmt.Println("String:", s) // 可以創建和打印
// 遍歷時，無效的 UTF-8 序列會被解碼為 RuneError (U+FFFD)
for i, r := range s {
fmt.Printf("Byte index %d: Rune %U (%q)\n", i, r, r)
}
}輸出：
String: ??? // 具體顯示取決于終端，但它包含非法序列
Byte index 0: Rune U+FFFD ('\uFFFD')
...此外，Go 1.1 允許 Go 源文件的起始處出現 Unicode 字節順序標記（BOM）U+FEFF（其 UTF-8 編碼為 EF BB BF）。雖然 UTF-8 編碼本身不需要 BOM，但有些編輯器會添加它作為文件編碼的標識，此更改提升了兼容性。
總的來說，這些關于 Unicode 的改動提高了 Go 對 Unicode 標準的遵從度，使得字符處理更加健壯，對大多數程序沒有影響，但依賴舊行為處理代理對的程序需要修改。
方法值（Method Values）
Go 1.1 引入了一個新特性：方法值（method values）。方法值是一個已綁定到特定接收器值的函數。與之相對的是已有的 方法表達式（method expressions），它會從一個類型的方法生成一個函數。
方法值 (Method Value)
當你擁有一個具體的值（接收器），并訪問它的某個方法但不立即調用它（即不加括號 ()），你就得到了一個方法值。這個方法值是一個函數，它內部“記住”了那個具體的接收器。調用這個方法值就等同于在原始接收器上調用該方法。
我們來看一個例子：
package main
import (
"fmt"
"strings"
)
type Greeter struct {
Name string
}
func (g Greeter) Greet() {
fmt.Printf("Hello, %s!\n", g.Name)
}
func main() {
g := Greeter{Name: "Alice"}
// 獲取方法值 greetFunc
// greetFunc 是一個函數，它已經綁定了接收器 g
greetFunc := g.Greet
// 調用方法值，就像調用普通函數一樣
greetFunc() // 輸出: Hello, Alice!
// greetFunc 的類型是 func()
fmt.Printf("Type of greetFunc: %T\n", greetFunc) // 輸出: Type of greetFunc: func()
// 這相當于閉包：
equivalentFunc := func() {
g.Greet() // 閉包捕獲了 g
}
equivalentFunc() // 輸出: Hello, Alice!
}在上面的例子中，g.Greet 就是一個方法值。它是一個 func() 類型的函數，調用它時，Greet 方法會在 g 這個實例上執行。
方法表達式 (Method Expression)
方法表達式則是基于 類型 而不是 實例 來獲取一個方法對應的函數。它的形式是 TypeName.MethodName 或 (*TypeName).MethodName。這個生成的函數會將接收器作為它的 第一個 參數。
繼續使用上面的 Greeter 類型：
package main
import (
"fmt"
"strings"
)
type Greeter struct {
Name string
}
func (g Greeter) Greet() {
fmt.Printf("Hello, %s!\n", g.Name)
}
// 一個接受 name 和 age 的方法
func (g Greeter) GreetPerson(name string, age int) {
fmt.Printf("Hello %s (%d), I'm %s.\n", name, age, g.Name)
}
func main() {
g1 := Greeter{Name: "Alice"}
g2 := Greeter{Name: "Bob"}
// 獲取 Greeter 類型 Greet 方法的方法表達式
// greetExprFunc 的類型是 func(Greeter)
greetExprFunc := Greeter.Greet
// 調用時，需要將接收器作為第一個參數傳入
greetExprFunc(g1) // 輸出: Hello, Alice!
greetExprFunc(g2) // 輸出: Hello, Bob!
fmt.Printf("Type of greetExprFunc: %T\n", greetExprFunc) // 輸出: Type of greetExprFunc: func(main.Greeter)
// 獲取 GreetPerson 方法的方法表達式
// greetPersonExprFunc 的類型是 func(Greeter, string, int)
greetPersonExprFunc := Greeter.GreetPerson
greetPersonExprFunc(g1, "Charlie", 30) // 輸出: Hello Charlie (30), I'm Alice.
greetPersonExprFunc(g2, "David", 25) // 輸出: Hello David (25), I'm Bob.
fmt.Printf("Type of greetPersonExprFunc: %T\n", greetPersonExprFunc) // 輸出: Type of greetPersonExprFunc: func(main.Greeter, string, int)
}方法表達式 Greeter.Greet 生成了一個類型為 func(Greeter) 的函數。調用它時，需要顯式地傳入一個 Greeter 類型的實例作為第一個參數，這個實例就充當了該次調用的接收器。同理，Greeter.GreetPerson 生成了一個 func(Greeter, string, int) 類型的函數。
總結對比
- **方法值 (instance.Method)**：綁定到 特定實例，函數簽名不包含接收器。
- **方法表達式 (Type.Method)**：基于 類型，生成的函數簽名將接收器作為 第一個參數。
這個特性是完全向后兼容的，不會影響任何現有代碼的編譯和運行。它為 Go 語言在函數式編程風格和接口使用方面提供了更大的靈活性。
64 位平臺 int 大小的變化
Go 語言規范允許 int 和 uint 類型的大小根據目標平臺是 32 位還是 64 位來決定。在 Go 1.1 之前，所有的 Go 實現都將 int 和 uint 定義為 32 位。
從 Go 1.1 開始，gc（標準編譯器）和 gccgo 實現在 64 位平臺（如 AMD64/x86-64）上將 int 和 uint 定義為 64 位。這一變化的主要好處之一是，它使得在 64 位系統上可以創建和操作元素數量超過 2^31（大約 20 億）的切片或執行需要更大整數范圍的計算。
由于 Go 強制要求顯式類型轉換，不允許在不同的數字類型之間進行隱式轉換，因此這個改變不會導致任何現有程序編譯失敗。
但是，如果程序中包含了 int 始終是 32 位的 隱式假設，那么其行為可能會在 64 位平臺上發生改變。一個典型的例子涉及到從一個無符號 32 位整數轉換為 int：
package main
import "fmt"
func main() {
// x 的值是 0xffffffff (即 2^32 - 1)
x := ^uint32(0)
fmt.Printf("x (uint32): %x\n", x)
// 將 x 轉換為 int
i := int(x)
// 在 32 位系統上:
// int 是 32 位，int(0xffffffff) 會被解釋為 -1 (二進制補碼表示)
// 輸出: i (int): -1 (on 32-bit systems)
// 在 64 位系統上 (Go 1.1+):
// int 是 64 位，int(0xffffffff) 會被零擴展為 64 位，值仍為 0xffffffff
// 輸出: i (int): 4294967295 (on 64-bit systems)
fmt.Printf("i (int): %d\n", i)
}在 32 位系統上，int 和 uint32 大小相同，將 0xffffffff 轉換為 int 時，其位模式保持不變，根據 int（有符號類型）的解釋，這個位模式代表 -1。
但在 Go 1.1 及以后版本的 64 位系統上，int 是 64 位。當將 32 位的 x (值為 0xffffffff) 轉換為 64 位的 int 時，會進行零擴展（因為源類型是無符號的），結果是 64 位的 0x00000000ffffffff，其十進制值是 4294967295。
如果你的代碼需要確保無論在哪種平臺，都執行 32 位的符號擴展（即將 0xffffffff 轉換為 -1），應該先顯式地將值轉換為 int32，再轉換為 int：
package main
import "fmt"
func main() {
x := ^uint32(0) // x is 0xffffffff
// 先轉換為 int32，再轉換為 int
// int32(x) 的值是 -1
// int(-1) 在 32 位和 64 位 int 上都是 -1
i := int(int32(x))
fmt.Printf("Portable i (int): %d\n", i) // 在所有平臺上都輸出 -1
}通過 int32(x)，我們將 0xffffffff 強制解釋為 32 位有符號整數，得到 -1。然后 int(-1) 在任何位數的 int 上結果都是 -1。
這個改動對大部分程序是透明的，但開發者應檢查代碼中是否存在對 int 位寬的隱藏假設，尤其是在進行位運算或與底層系統、特定數據格式交互時。
go 命令的改進
Go 1.1 對 go 命令行工具進行了一些旨在改善新用戶體驗和規范項目管理的改動。
1. 更詳細的包未找到錯誤信息
當使用 go build, go test 或 go run 等命令時，如果無法定位所需的包，go 命令現在會提供更詳細的錯誤輸出。錯誤信息會包含它嘗試搜索包的具體路徑列表，這些路徑基于 $GOROOT 和 $GOPATH 環境變量。
例如，如果嘗試構建一個不存在的包 foo/quxx：
$ go build foo/quxx
can't load package: package foo/quxx: cannot find package "foo/quxx" in any of:
/usr/local/go/src/pkg/foo/quxx (from $GOROOT) # 假設 $GOROOT 是 /usr/local/go
/home/user/go/src/foo/quxx (from $GOPATH) # 假設 $GOPATH 是 /home/user/go這個改進讓開發者能更快地診斷出是 $GOPATH 設置不正確、包未下載還是路徑拼寫錯誤等問題。
2. go get 強制要求 $GOPATH
go get 命令用于下載和安裝包及其依賴。在 Go 1.1 中，go get 不再允許在沒有設置有效 $GOPATH 的情況下運行，并且不再隱式地將 $GOROOT 作為下載目標。現在，必須設置一個有效的 $GOPATH 環境變量，go get 會將下載的源碼放在 $GOPATH/src 目錄下。
如果 $GOPATH 未設置：
$ GOPATH= go get example.com/some/package
package example.com/some/package: cannot download, $GOPATH not set. For more details see: go help gopath3. go get 禁止 $GOPATH 與 $GOROOT 相同
作為上一條規則的延伸，Go 1.1 還禁止將 $GOPATH 設置為與 $GOROOT 相同的值。$GOROOT 指向 Go 的安裝目錄，包含標準庫源碼，而 $GOPATH 指向用戶的工作區，包含第三方庫和用戶自己的項目代碼。將兩者混用會導致管理混亂。
如果 $GOPATH 被設置為 $GOROOT：
$ export GOPATH=$GOROOT # 假設 GOROOT 是 /usr/local/go
$ go get example.com/some/package
warning: GOPATH set to GOROOT (/usr/local/go) has no effect
package example.com/some/package: cannot download, $GOPATH must not be set to $GOROOT. For more details see: go help gopath這些對 go 命令的改動，特別是圍繞 $GOPATH 的調整，旨在引導開發者從一開始就采用標準的 Go 工作區布局，這對于管理依賴和項目結構至關重要，尤其是在 Go Modules 出現之前。
