Go 1.13 相比 Go 1.12 有哪些值得注意的改動？
https://go.dev/doc/go1.13
Go 1.13 帶來了一系列語言、工具鏈、運行時和標準庫的改進。以下是一些值得開發者關注的重點改動：
- 語言特性 ： 引入了更統一和現代化的數字字面量表示法，包括二進制 (
0b)、八進制 (0o) 前綴、十六進制浮點數、數字分隔符 (_) 等，并取消了移位操作計數必須為無符號數的限制。 - Go Modules 與 Go 命令 ：
GO111MODULE=auto在檢測到go.mod文件時將默認啟用模塊感知模式，即使在GOPATH內；引入GOPRIVATE等環境變量更好地管理私有模塊和代理配置；go get -u的更新邏輯有所調整；go命令增加了如go env -w、go version <executable>、go build -trimpath等新功能。 - Runtime 運行時 ： 優化了切片越界時的 panic 信息，使其包含越界索引和切片長度；
defer的性能在大多數場景下提升了約 30%；運行時會更積極地將不再使用的內存歸還給操作系統。 - 錯誤處理 ： 正式引入了 錯誤包裝（error wrapping）機制，通過
fmt.Errorf的新%w動詞和errors包新增的Unwrap、Is、As函數，可以創建和檢查包含原始錯誤上下文的錯誤鏈。 sync包 ： 通過內聯優化，sync.Mutex、sync.RWMutex和sync.Once在非競爭情況下的性能得到提升（鎖操作約 10%，Once.Do約 2 倍）；sync.Pool對 GC 暫停時間（STW）的影響減小，并且能在 GC 后保留部分對象，減少 GC 后的冷啟動開銷。
下面是一些值得展開的討論：
語言特性：更現代化的數字字面量與有符號位移
Go 1.13 在語言層面引入了幾項旨在提升代碼可讀性和易用性的改進。
首先是數字字面量的增強：
- 二進制字面量 (Binary Literals) ： 使用前綴
0b或0B表示二進制整數，例如0b1011代表十進制的 11。 - 八進制字面量 (Octal Literals) ： 使用前綴
0o或0O表示八進制整數，例如0o660代表十進制的 432。需要注意的是，舊式的以0開頭的八進制表示法（如0660）仍然有效，但推薦使用新的0o前綴以避免歧義。 - 十六進制浮點數字面量 (Hexadecimal Floating-point Literals) ： 允許使用
0x或0X前綴表示浮點數的尾數部分，但必須帶有一個以p或P開頭的二進制指數。例如0x1.0p-2表示 ，即 0.25。 - 虛數字面量后綴 (Imaginary Literals) ： 虛數后綴
i現在可以用于任何整數或浮點數字面量（二進制、八進制、十進制、十六進制），如0b1011i、0o660i、3.14i、0x1.fp+2i。 - 數字分隔符 (Digit Separators) ： 可以使用下劃線
_來分隔數字，以提高長數字的可讀性，例如1_000_000、0b_1010_0110或3.1415_9265。下劃線可以出現在任意兩個數字之間，或者前綴和第一個數字之間。
package main
import "fmt"
func main() {
binaryNum := 0b1101 // 13
octalNum := 0o755 // 493
hexFloat := 0x1.Fp+2 // 1.9375 * 2^2 = 7.75
largeNum := 1_000_000_000
complexNum := 0xAp1 + 1_2i // (10 * 2^1) + 12i = 20 + 12i
fmt.Println(binaryNum)
fmt.Println(octalNum)
fmt.Println(hexFloat)
fmt.Println(largeNum)
fmt.Println(complexNum)
// 13
// 493
// 7.75
// 1000000000
// (20+12i)
}其次，Go 1.13 取消了移位操作（<< 和 >>）的移位計數（右操作數）必須是無符號整數的限制。現在可以直接使用有符號整數作為移位計數。
這消除了之前為了滿足類型要求而進行的許多不自然的 uint 轉換。
package main
import "fmt"
func main() {
var signedShift int = 2
var value int64 = 100
// Go 1.12 及之前: 需要顯式轉換為 uint
// shiftedValueOld := value << uint(signedShift)
// Go 1.13 及之后: 可以直接使用 signed int
shiftedValueNew := value << signedShift
// fmt.Println(shiftedValueOld) // 輸出 400
fmt.Println(shiftedValueNew) // 輸出 400
var negativeShift int = -2 // 負數移位也是允許的，但行為依賴于具體實現和架構，通常不建議
fmt.Println(value >> negativeShift) // 行為可能非預期，輸出可能為 0 或 panic，取決于 Go 版本和具體情況
}400
panic: runtime error: negative shift amount
goroutine 1 [running]:
main.main()
/home/piperliu/code/playground/main.go:19 +0x85
exit status 2需要注意的是，要使用這些新的語言特性，你的項目需要使用 Go Modules，并且 go.mod 文件中聲明的 Go 版本至少為 1.13。你可以手動編輯 go.mod 文件，或者運行 go mod edit -go=1.13 來更新。
Go Modules 與 Go 命令：模塊化體驗改進與工具增強
Go 1.13 在 Go Modules 和 go 命令行工具方面帶來了重要的改進，旨在簡化開發流程和模塊管理。
模塊行為與環境變量
GO111MODULE=auto的行為變化：現在，只要當前工作目錄或其任何父目錄包含go.mod文件，auto設置就會激活模塊感知模式。這意味著即使項目位于傳統的GOPATH/src目錄下，只要存在go.mod，go命令也會優先使用模塊模式。這極大地簡化了從GOPATH遷移到 Modules 的過程以及混合管理兩種模式項目的場景。- 新的環境變量
GOPRIVATE、GONOPROXY、GONOSUMDB：為了更好地處理私有模塊（例如公司內部的代碼庫），引入了GOPRIVATE環境變量。它用于指定一組不應通過公共代理 (GOPROXY) 下載或通過公共校驗和數據庫 (GOSUMDB) 驗證的模塊路徑模式（支持通配符）。GOPRIVATE會作為GONOPROXY和GONOSUMDB的默認值，提供更細粒度的控制。 GOPROXY默認值與配置：GOPROXY環境變量現在支持逗號分隔的代理 URL 列表，以及特殊值direct（表示直接連接源倉庫）。其默認值更改為https://proxy.golang.org,direct。go命令會按順序嘗試列表中的每個代理，直到成功下載或遇到非 404/410 錯誤。GOSUMDB：用于指定校驗和數據庫的名稱和可選的公鑰及 URL。默認值為sum.golang.org。如果模塊不在主模塊的go.sum文件中，go命令會查詢GOSUMDB以驗證下載模塊的哈希值，確保依賴未被篡改。可以設置為off來禁用此檢查。
對于無法訪問公共代理或校驗和數據庫的環境（如防火墻內），可以使用 go env -w 命令設置全局默認值：
# 僅直接從源倉庫下載，不使用代理
go env -w GOPROXY=direct
# 禁用校驗和數據庫檢查
go env -w GOSUMDB=off
# 配置私有模塊路徑 (示例)
go env -w GOPRIVATE=*.corp.example.com,github.com/my-private-org/*go get 行為調整
go get -u的更新范圍：在模塊模式下，go get -u（不帶包名參數時）現在只更新當前目錄包的直接和間接依賴。這與GOPATH模式下的行為更一致。如果要更新go.mod中定義的所有依賴（包括測試依賴）到最新版本，應使用go get -u all。go get -u <package>的更新范圍：當指定包名時，go get -u <package>會更新指定的包及其導入的包所在的模塊，而不是這些模塊的所有傳遞依賴。@patch版本后綴：go get支持了新的@patch版本后綴。例如go get example.com/mod@patch會將example.com/mod更新到當前主版本和次版本下的最新補丁版本。@upgrade和@latest：@upgrade明確要求將模塊升級到比當前更新的版本（如果沒有新版本則保持不變，防止意外降級預發布版本）。@latest則總是嘗試獲取最新的發布版本，無論當前版本如何。
版本校驗增強
go 命令在處理模塊版本時增加了更嚴格的校驗：
+incompatible版本：如果一個倉庫使用了+incompatible標記（通常用于 Modules 出現之前的 v2+ 版本），go命令現在會驗證該版本對應的代碼樹中 不能 包含go.mod文件。- 偽版本 (Pseudo-versions)：對形如
vX.Y.Z-yyyymmddhhmmss-abcdefabcdef的偽版本格式進行了更嚴格的校驗，確保版本前綴、時間戳和 commit 哈希與版本控制系統的元數據一致。如果go.mod中有無效的偽版本，通常可以通過將其簡化為 commit 哈希（如require example.com/mod abcdefabcdef）然后運行go mod tidy或go list -m all來自動修正。對于傳遞依賴中的無效版本，可以使用replace指令強制替換為有效的版本或 commit 哈希。
其他 go 命令改進
go env -w和-u：允許設置和取消設置go命令環境變量的用戶級默認值，存儲在用戶配置目錄下的go/env文件中。go version <executable>或<directory>：可以查看 Go 二進制文件是用哪個 Go 版本編譯的（使用-m標志可查看嵌入的模塊信息），或查看目錄及其子目錄下所有 Go 二進制文件的版本信息。go build -trimpath：一個新的構建標志，用于從編譯出的二進制文件中移除所有本地文件系統路徑信息，有助于提高構建的可復現性。
錯誤處理：官方錯誤包裝（Error Wrapping）機制
Go 1.13 引入了一個重要的原生機制來處理錯誤： 錯誤包裝 (error wrapping) 。這個特性解決了長期以來在 Go 中處理錯誤時的一個痛點：如何在添加上下文信息的同時，保留底層原始錯誤以便進行程序化檢查。
問題背景
在 Go 1.13 之前，當一個函數遇到來自底層調用的錯誤，并想添加更多關于當前操作的上下文信息時，通常的做法是使用 fmt.Errorf 創建一個新的錯誤字符串，包含原始錯誤的信息（通過 %v 或 err.Error()）。
// Go 1.13 之前的常見做法
func readFile(path string) error {
f, err := os.Open(path)
if err != nil {
// 創建了新錯誤，丟失了原始 err 的類型信息 (如 *os.PathError)
return fmt.Errorf("failed to open file %q: %v", path, err)
}
// ...
defer f.Close()
return nil
}
func checkPermission() {
err := readFile("/path/to/protected/file")
// 無法直接判斷 err 是否是權限錯誤，因為原始的 os.ErrPermission 信息丟失了
// if err == os.ErrPermission { ... } // 這通常行不通
}這種方式的問題在于，返回的錯誤是一個全新的 string 類型的錯誤（由 fmt.Errorf 創建），原始錯誤的類型信息（例如 *os.PathError）和值（例如 os.ErrNotExist）丟失了。調用者無法方便地檢查錯誤的根本原因，例如判斷它是不是一個特定的錯誤類型或哨兵錯誤值（sentinel error）。
Go 1.13 的解決方案：%w, Unwrap, Is, As
Go 1.13 通過以下方式解決了這個問題：
fmt.Errorf 的 %w 動詞
fmt.Errorf 函數增加了一個新的格式化動詞 %w。當使用 %w 來格式化一個錯誤時，fmt.Errorf 會創建一個新的錯誤，這個新錯誤不僅包含了格式化后的字符串信息，還 包裝 (wrap) 了原始的錯誤。這個包裝后的錯誤會實現一個 Unwrap() error 方法，該方法返回被包裝的原始錯誤。
package main
import (
"errors"
"fmt"
"os"
"io/fs" // fs.ErrNotExist 在 Go 1.16 引入，之前是 os.ErrNotExist
)
// queryDatabase 模擬數據庫查詢錯誤
var ErrDBConnection = errors.New("database connection failed")
func queryDatabase(query string) error {
// 模擬連接失敗
return ErrDBConnection
}
// handleRequest 處理請求，調用數據庫查詢
func handleRequest(req string) error {
err := queryDatabase(req)
if err != nil {
// 使用 %w 包裝原始錯誤 ErrDBConnection
return fmt.Errorf("failed to handle request '%s': %w", req, err)
}
return nil
}
// readFileWithErrorWrapping 示例
func readFileWithErrorWrapping(path string) error {
_, err := os.Open(path)
if err != nil {
// 使用 %w 包裝 os.Open 返回的錯誤
return fmt.Errorf("error opening file %s: %w", path, err)
}
return nil
}
func main() {
// 場景1：檢查特定的哨兵錯誤
err := handleRequest("SELECT * FROM users")
if err != nil {
fmt.Printf("Original error: %v\n", err) // 輸出包含包裝信息
// 使用 errors.Is 檢查錯誤鏈中是否包含 ErrDBConnection
if errors.Is(err, ErrDBConnection) {
fmt.Println("Error check passed: The root cause is ErrDBConnection.")
} else {
fmt.Println("Error check failed: The root cause is NOT ErrDBConnection.")
}
}
fmt.Println("---")
// 場景2：檢查特定的錯誤類型并獲取其值
errFile := readFileWithErrorWrapping("non_existent_file.txt")
if errFile != nil {
fmt.Printf("Original file error: %v\n", errFile)
// 使用 errors.As 檢查錯誤鏈中是否有 *fs.PathError 類型
// 并將該類型的錯誤值賦給 pathErr
var pathErr *fs.PathError
if errors.As(errFile, &pathErr) {
fmt.Printf("Error check passed: It's a PathError.\n")
fmt.Printf(" Operation: %s\n", pathErr.Op)
fmt.Printf(" Path: %s\n", pathErr.Path)
fmt.Printf(" Underlying error: %v\n", pathErr.Err) // 底層具體錯誤
} else {
fmt.Println("Error check failed: It's NOT a PathError.")
}
// 也可以用 errors.Is 檢查底層的哨兵錯誤
if errors.Is(errFile, fs.ErrNotExist) {
fmt.Println("Further check: The underlying error IS fs.ErrNotExist.")
}
}
}errors.Unwrap(err error) error
這個函數接收一個錯誤 err。如果 err 實現了 Unwrap() error 方法，errors.Unwrap 會調用它并返回其結果（即被包裝的那個錯誤）。如果 err 沒有包裝其他錯誤，則返回 nil。這允許你手動地逐層解開錯誤鏈。
errors.Is(err error, target error) bool
這是檢查錯誤鏈的首選方式。它會遞歸地解開 err 的錯誤鏈（通過調用 Unwrap），檢查鏈中的任何一個錯誤是否 等于target 哨兵錯誤值（使用 == 比較）。如果找到匹配項，返回 true。這對于檢查是否發生了某個已知的、預定義的錯誤（如 io.EOF, sql.ErrNoRows, 或自定義的哨兵錯誤）非常有用。
errors.As(err error, target interface{}) bool
這也是檢查錯誤鏈的首選方式。它會遞歸地解開 err 的錯誤鏈，檢查鏈中的任何一個錯誤是否可以賦值給target 指向的類型。如果找到匹配項，它會將該錯誤值賦給 target（target 必須是一個指向錯誤類型接口或具體錯誤類型的指針），并返回 true。這對于檢查錯誤是否屬于某個特定類型，并希望獲取該類型錯誤的具體字段信息（如 *os.PathError 的 Op 和 Path 字段）非常有用。
最佳實踐
- 當你想給一個錯誤添加上下文，并且希望調用者能夠檢查或響應原始錯誤時，使用
fmt.Errorf的%w動詞進行包裝。 - 當你只想記錄錯誤信息，不關心調用者是否需要檢查原始錯誤時，繼續使用
%v或err.Error()。 - 優先使用
errors.Is來檢查錯誤鏈中是否包含特定的哨兵錯誤值。 - 優先使用
errors.As來檢查錯誤鏈中是否包含特定類型的錯誤，并獲取該錯誤的值以訪問其字段。 - 避免直接調用
Unwrap方法，除非你有特殊需要逐層處理錯誤鏈。errors.Is和errors.As通常是更健壯和方便的選擇。
錯誤包裝機制極大地增強了 Go 的錯誤處理能力，使得構建更健壯、更易于調試和維護的程序成為可能。
sync 包：性能優化與 sync.Pool 改進
Go 1.13 對 sync 包中的一些常用同步原語進行了性能優化，并改進了 sync.Pool 的行為。
鎖和 Once 的性能提升
sync.Mutex（互斥鎖）、sync.RWMutex（讀寫鎖）和 sync.Once（保證函數只執行一次）是非常基礎且常用的同步工具。
sync.Mutex: 用于保護臨界區，確保同一時間只有一個 goroutine 可以訪問共享資源。
var mu sync.Mutex
var counter int
func increment() {
mu.Lock() // 獲取鎖
defer mu.Unlock() // 保證釋放鎖
counter++
}sync.RWMutex: 允許多個讀取者同時訪問資源，但寫入者必須獨占訪問。適用于讀多寫少的場景。
var rwMu sync.RWMutex
var config map[string]string
func getConfig(key string) string {
rwMu.RLock() // 獲取讀鎖
defer rwMu.RUnlock() // 釋放讀鎖
return config[key]
}
func setConfig(key, value string) {
rwMu.Lock() // 獲取寫鎖
defer rwMu.Unlock() // 釋放寫鎖
config[key] = value
}sync.Once: 用于確保某個初始化操作或其他需要只執行一次的動作，在并發環境下確實只執行一次。
var once sync.Once
var serviceInstance *Service
func GetService() *Service {
once.Do(func() {
// 初始化操作，只會在首次調用 Do 時執行
serviceInstance = &Service{}
serviceInstance.init()
})
return serviceInstance
}在 Go 1.13 中，這些原語的 快速路徑 (fast path) （即沒有發生鎖競爭或 Once.Do 已經被執行過的情況）被 內聯 (inlined) 到了調用者的代碼中。這意味著在最常見、性能最關鍵的非競爭場景下，調用這些方法的開銷顯著降低。根據官方說明，在 amd64 架構下：
Mutex.Lock,Mutex.Unlock,RWMutex.Lock,RWMutex.RUnlock的非競爭情況性能提升高達 10%。Once.Do在非首次執行時（即once已經被觸發后）的速度提升了大約 2 倍。
sync.Pool 的改進
sync.Pool 是一個用于存儲和復用臨時對象的技術，主要目的是減少內存分配次數和 GC 壓力，尤其適用于那些需要頻繁創建和銷毀、生命周期短暫的對象（如網絡連接的緩沖區、編解碼器的狀態對象等）。
var bufferPool = sync.Pool{
New: func() interface{} {
// New 函數用于在 Pool 為空時創建新對象
fmt.Println("Allocating new buffer")
return make([]byte, 4096) // 例如創建一個 4KB 的緩沖區
},
}
func handleConnection(conn net.Conn) {
// 從 Pool 獲取一個 buffer
buf := bufferPool.Get().([]byte)
// 使用 buffer ...
n, err := conn.Read(buf)
// ...
// 將 buffer 放回 Pool 以便復用
// 注意：放回前最好清理一下 buffer 內容（如果需要）
// e.g., buf = buf[:0] or zero out parts of it
bufferPool.Put(buf)
}Go 1.13 對 sync.Pool 做了兩項重要改進：
- 減少對 GC STW (Stop-The-World) 暫停時間的影響 ：在之前的版本中，如果
sync.Pool中緩存了大量對象，清理這些對象（尤其是在 GC 期間）可能會對 STW 暫停時間產生比較明顯的影響。Go 1.13 優化了sync.Pool的內部實現，使得即使池中對象很多，對 GC 暫停時間的影響也顯著減小。 - 跨 GC 保留部分對象 ：這是
sync.Pool行為的一個重大變化。在 Go 1.13 之前， 每次 GC 運行時，sync.Pool中的所有緩存對象都會被無條件清除 。這意味著每次 GC 之后，如果程序繼續請求對象，Pool會變空，導致大量調用New函數來重新填充緩存，這可能在 GC 后造成短暫的性能抖動（分配和 GC 壓力增加）。
從 Go 1.13 開始，sync.Pool可以在 GC 之后保留一部分之前緩存的對象 。它使用了一個兩階段的緩存機制，主緩存池仍然會在 GC 時被清理，但會有一個備用（受害者）緩存池保留上一次 GC 清理掉的對象，供本次 GC 后使用。這樣，GC 之后 Pool 不再是完全空的，可以更快地提供緩存對象，減少了對 New 的調用頻率，從而平滑了 GC 后的性能表現，降低了負載峰值。
使用 sync.Pool 的注意事項（結合 1.13 改進）
sync.Pool仍然適用于臨時對象的復用，以減少分配和 GC 壓力。- 由于對象現在可能跨 GC 保留，從
Pool中Get到的對象可能包含上次使用時殘留的數據。因此，在使用前對其進行必要的 重置或清理 變得更加重要（例如，對于[]byte，使用buf = buf[:0]；對于結構體，清零關鍵字段）。 Pool保留對象的能力并不意味著你可以用它來管理需要精確生命周期控制的資源（如文件句柄、網絡連接），這些資源通常需要顯式的Close方法。- 雖然跨 GC 保留對象減少了冷啟動開銷，但也意味著
Pool可能會持有內存更長時間。不過，Go 1.13 運行時本身也改進了內存歸還給操作系統的策略，這在一定程度上平衡了這一點。
總的來說，Go 1.13 中 sync 包的改進提升了常用同步原語的性能，并使 sync.Pool 在高并發和頻繁 GC 的場景下表現更加穩定和高效。
