https://go.dev/doc/go1.13

Go 1.13 帶來了一系列語言、工具鏈、運行時和標準庫的改進。以下是一些值得開發(fā)者關注的重點改動：

• 語言特性 ： 引入了更統(tǒng)一和現(xiàn)代化的數(shù)字字面量表示法，包括二進制 (0b)、八進制 (0o) 前綴、十六進制浮點數(shù)、數(shù)字分隔符 (_) 等，并取消了移位操作計數(shù)必須為無符號數(shù)的限制。
• Go Modules 與 Go 命令 ： GO111MODULE=auto 在檢測到 go.mod 文件時將默認啟用模塊感知模式，即使在 GOPATH 內(nèi)；引入 GOPRIVATE 等環(huán)境變量更好地管理私有模塊和代理配置；go get -u 的更新邏輯有所調(diào)整；go 命令增加了如 go env -w、go version <executable>、go build -trimpath 等新功能。
• Runtime 運行時 ： 優(yōu)化了切片越界時的 panic 信息，使其包含越界索引和切片長度；defer 的性能在大多數(shù)場景下提升了約 30%；運行時會更積極地將不再使用的內(nèi)存歸還給操作系統(tǒng)。
• 錯誤處理 ： 正式引入了 錯誤包裝（error wrapping）機制，通過 fmt.Errorf 的新 %w 動詞和 errors 包新增的 Unwrap、Is、As 函數(shù)，可以創(chuàng)建和檢查包含原始錯誤上下文的錯誤鏈。
• sync 包 ： 通過內(nèi)聯(lián)優(yōu)化，sync.Mutex、sync.RWMutex 和 sync.Once 在非競爭情況下的性能得到提升（鎖操作約 10%，Once.Do 約 2 倍）；sync.Pool 對 GC 暫停時間（STW）的影響減小，并且能在 GC 后保留部分對象，減少 GC 后的冷啟動開銷。

下面是一些值得展開的討論：

語言特性：更現(xiàn)代化的數(shù)字字面量與有符號位移

Go 1.13 在語言層面引入了幾項旨在提升代碼可讀性和易用性的改進。

首先是數(shù)字字面量的增強：

• 二進制字面量 (Binary Literals) ： 使用前綴 0b 或 0B 表示二進制整數(shù)，例如 0b1011 代表十進制的 11。
• 八進制字面量 (Octal Literals) ： 使用前綴 0o 或 0O 表示八進制整數(shù)，例如 0o660 代表十進制的 432。需要注意的是，舊式的以 0 開頭的八進制表示法（如 0660）仍然有效，但推薦使用新的 0o 前綴以避免歧義。
• 十六進制浮點數(shù)字面量 (Hexadecimal Floating-point Literals) ： 允許使用 0x 或 0X 前綴表示浮點數(shù)的尾數(shù)部分，但必須帶有一個以 p 或 P 開頭的二進制指數(shù)。例如 0x1.0p-2 表示 ，即 0.25。
• 虛數(shù)字面量后綴 (Imaginary Literals) ： 虛數(shù)后綴 i 現(xiàn)在可以用于任何整數(shù)或浮點數(shù)字面量（二進制、八進制、十進制、十六進制），如 0b1011i、0o660i、3.14i、0x1.fp+2i。
• 數(shù)字分隔符 (Digit Separators) ： 可以使用下劃線 _ 來分隔數(shù)字，以提高長數(shù)字的可讀性，例如 1_000_000、0b_1010_0110 或 3.1415_9265。下劃線可以出現(xiàn)在任意兩個數(shù)字之間，或者前綴和第一個數(shù)字之間。

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 取消了移位操作（<< 和 >>）的移位計數(shù)（右操作數(shù)）必須是無符號整數(shù)的限制?，F(xiàn)在可以直接使用有符號整數(shù)作為移位計數(shù)。

這消除了之前為了滿足類型要求而進行的許多不自然的 uint 轉(zhuǎn)換。

package main

import "fmt"

func main() {
    var signedShift int = 2
    var value int64 = 100

    // Go 1.12 及之前: 需要顯式轉(zhuǎn)換為 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 // 負數(shù)移位也是允許的，但行為依賴于具體實現(xiàn)和架構，通常不建議
    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 命令行工具方面帶來了重要的改進，旨在簡化開發(fā)流程和模塊管理。

模塊行為與環(huán)境變量

• GO111MODULE=auto 的行為變化：現(xiàn)在，只要當前工作目錄或其任何父目錄包含 go.mod 文件，auto 設置就會激活模塊感知模式。這意味著即使項目位于傳統(tǒng)的 GOPATH/src 目錄下，只要存在 go.mod，go 命令也會優(yōu)先使用模塊模式。這極大地簡化了從 GOPATH 遷移到 Modules 的過程以及混合管理兩種模式項目的場景。
• 新的環(huán)境變量 GOPRIVATE、GONOPROXY、GONOSUMDB：為了更好地處理私有模塊（例如公司內(nèi)部的代碼庫），引入了 GOPRIVATE 環(huán)境變量。它用于指定一組不應通過公共代理 (GOPROXY) 下載或通過公共校驗和數(shù)據(jù)庫 (GOSUMDB) 驗證的模塊路徑模式（支持通配符）。GOPRIVATE 會作為 GONOPROXY 和 GONOSUMDB 的默認值，提供更細粒度的控制。
• GOPROXY 默認值與配置：GOPROXY 環(huán)境變量現(xiàn)在支持逗號分隔的代理 URL 列表，以及特殊值 direct（表示直接連接源倉庫）。其默認值更改為 https://proxy.golang.org,direct。go 命令會按順序嘗試列表中的每個代理，直到成功下載或遇到非 404/410 錯誤。
• GOSUMDB：用于指定校驗和數(shù)據(jù)庫的名稱和可選的公鑰及 URL。默認值為 sum.golang.org。如果模塊不在主模塊的 go.sum 文件中，go 命令會查詢 GOSUMDB 以驗證下載模塊的哈希值，確保依賴未被篡改。可以設置為 off 來禁用此檢查。

對于無法訪問公共代理或校驗和數(shù)據(jù)庫的環(huán)境（如防火墻內(nèi)），可以使用 go env -w 命令設置全局默認值：

# 僅直接從源倉庫下載，不使用代理
go env -w GOPROXY=direct

# 禁用校驗和數(shù)據(jù)庫檢查
go env -w GOSUMDB=off

# 配置私有模塊路徑 (示例)
go env -w GOPRIVATE=*.corp.example.com,github.com/my-private-org/*

go get 行為調(diào)整

• go get -u 的更新范圍：在模塊模式下，go get -u （不帶包名參數(shù)時）現(xiàn)在只更新當前目錄包的直接和間接依賴。這與 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 明確要求將模塊升級到比當前更新的版本（如果沒有新版本則保持不變，防止意外降級預發(fā)布版本）。@latest 則總是嘗試獲取最新的發(fā)布版本，無論當前版本如何。

版本校驗增強

go 命令在處理模塊版本時增加了更嚴格的校驗：

• +incompatible 版本：如果一個倉庫使用了 +incompatible 標記（通常用于 Modules 出現(xiàn)之前的 v2+ 版本），go 命令現(xiàn)在會驗證該版本對應的代碼樹中 不能 包含 go.mod 文件。
• 偽版本 (Pseudo-versions)：對形如 vX.Y.Z-yyyymmddhhmmss-abcdefabcdef 的偽版本格式進行了更嚴格的校驗，確保版本前綴、時間戳和 commit 哈希與版本控制系統(tǒng)的元數(shù)據(jù)一致。如果 go.mod 中有無效的偽版本，通?？梢酝ㄟ^將其簡化為 commit 哈希（如 require example.com/mod abcdefabcdef）然后運行 go mod tidy 或 go list -m all 來自動修正。對于傳遞依賴中的無效版本，可以使用 replace 指令強制替換為有效的版本或 commit 哈希。

其他 go 命令改進

• go env -w 和 -u：允許設置和取消設置 go 命令環(huán)境變量的用戶級默認值，存儲在用戶配置目錄下的 go/env 文件中。
• go version <executable> 或 <directory>：可以查看 Go 二進制文件是用哪個 Go 版本編譯的（使用 -m 標志可查看嵌入的模塊信息），或查看目錄及其子目錄下所有 Go 二進制文件的版本信息。
• go build -trimpath：一個新的構建標志，用于從編譯出的二進制文件中移除所有本地文件系統(tǒng)路徑信息，有助于提高構建的可復現(xiàn)性。

錯誤處理：官方錯誤包裝（Error Wrapping）機制

Go 1.13 引入了一個重要的原生機制來處理錯誤： 錯誤包裝 (error wrapping) 。這個特性解決了長期以來在 Go 中處理錯誤時的一個痛點：如何在添加上下文信息的同時，保留底層原始錯誤以便進行程序化檢查。

問題背景

在 Go 1.13 之前，當一個函數(shù)遇到來自底層調(diào)用的錯誤，并想添加更多關于當前操作的上下文信息時，通常的做法是使用 fmt.Errorf 創(chuàng)建一個新的錯誤字符串，包含原始錯誤的信息（通過 %v 或 err.Error()）。

// Go 1.13 之前的常見做法
func readFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        // 創(chuàng)建了新錯誤，丟失了原始 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 創(chuàng)建），原始錯誤的類型信息（例如 *os.PathError）和值（例如 os.ErrNotExist）丟失了。調(diào)用者無法方便地檢查錯誤的根本原因，例如判斷它是不是一個特定的錯誤類型或哨兵錯誤值（sentinel error）。

Go 1.13 的解決方案：%w, Unwrap, Is, As

Go 1.13 通過以下方式解決了這個問題：

fmt.Errorf 的 %w 動詞

fmt.Errorf 函數(shù)增加了一個新的格式化動詞 %w。當使用 %w 來格式化一個錯誤時，fmt.Errorf 會創(chuàng)建一個新的錯誤，這個新錯誤不僅包含了格式化后的字符串信息，還 包裝 (wrap) 了原始的錯誤。這個包裝后的錯誤會實現(xiàn)一個 Unwrap() error 方法，該方法返回被包裝的原始錯誤。

package main

import (
    "errors"
    "fmt"
    "os"
    "io/fs" // fs.ErrNotExist 在 Go 1.16 引入，之前是 os.ErrNotExist
)

// queryDatabase 模擬數(shù)據(jù)庫查詢錯誤
var ErrDBConnection = errors.New("database connection failed")

func queryDatabase(query string) error {
    // 模擬連接失敗
    return ErrDBConnection
}

// handleRequest 處理請求，調(diào)用數(shù)據(jù)庫查詢
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

這個函數(shù)接收一個錯誤 err。如果 err 實現(xiàn)了 Unwrap() error 方法，errors.Unwrap 會調(diào)用它并返回其結果（即被包裝的那個錯誤）。如果 err 沒有包裝其他錯誤，則返回 nil。這允許你手動地逐層解開錯誤鏈。

1. errors.Is(err error, target error) bool

這是檢查錯誤鏈的首選方式。它會遞歸地解開 err 的錯誤鏈（通過調(diào)用 Unwrap），檢查鏈中的任何一個錯誤是否 等于target 哨兵錯誤值（使用 == 比較）。如果找到匹配項，返回 true。這對于檢查是否發(fā)生了某個已知的、預定義的錯誤（如 io.EOF, sql.ErrNoRows, 或自定義的哨兵錯誤）非常有用。

errors.As(err error, target interface{}) bool

這也是檢查錯誤鏈的首選方式。它會遞歸地解開 err 的錯誤鏈，檢查鏈中的任何一個錯誤是否可以賦值給target 指向的類型。如果找到匹配項，它會將該錯誤值賦給 target（target 必須是一個指向錯誤類型接口或具體錯誤類型的指針），并返回 true。這對于檢查錯誤是否屬于某個特定類型，并希望獲取該類型錯誤的具體字段信息（如 *os.PathError 的 Op 和 Path 字段）非常有用。

最佳實踐

• 當你想給一個錯誤添加上下文，并且希望調(diào)用者能夠檢查或響應原始錯誤時，使用 fmt.Errorf 的 %w 動詞進行包裝。
• 當你只想記錄錯誤信息，不關心調(diào)用者是否需要檢查原始錯誤時，繼續(xù)使用 %v 或 err.Error()。
• 優(yōu)先使用 errors.Is 來檢查錯誤鏈中是否包含特定的哨兵錯誤值。
• 優(yōu)先使用 errors.As 來檢查錯誤鏈中是否包含特定類型的錯誤，并獲取該錯誤的值以訪問其字段。
• 避免直接調(diào)用 Unwrap 方法，除非你有特殊需要逐層處理錯誤鏈。errors.Is 和 errors.As 通常是更健壯和方便的選擇。

錯誤包裝機制極大地增強了 Go 的錯誤處理能力，使得構建更健壯、更易于調(diào)試和維護的程序成為可能。

sync 包：性能優(yōu)化與 sync.Pool 改進

Go 1.13 對 sync 包中的一些常用同步原語進行了性能優(yōu)化，并改進了 sync.Pool 的行為。

鎖和 Once 的性能提升

sync.Mutex（互斥鎖）、sync.RWMutex（讀寫鎖）和 sync.Once（保證函數(shù)只執(zhí)行一次）是非?；A且常用的同步工具。

• sync.Mutex : 用于保護臨界區(qū)，確保同一時間只有一個 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 : 用于確保某個初始化操作或其他需要只執(zhí)行一次的動作，在并發(fā)環(huán)境下確實只執(zhí)行一次。

var once sync.Once
var serviceInstance *Service

func GetService() *Service {
 once.Do(func() {
  // 初始化操作，只會在首次調(diào)用 Do 時執(zhí)行
  serviceInstance = &Service{}
  serviceInstance.init()
 })
 return serviceInstance
}

在 Go 1.13 中，這些原語的 快速路徑 (fast path) （即沒有發(fā)生鎖競爭或 Once.Do 已經(jīng)被執(zhí)行過的情況）被 內(nèi)聯(lián) (inlined) 到了調(diào)用者的代碼中。這意味著在最常見、性能最關鍵的非競爭場景下，調(diào)用這些方法的開銷顯著降低。根據(jù)官方說明，在 amd64 架構下：

• Mutex.Lock, Mutex.Unlock, RWMutex.Lock, RWMutex.RUnlock 的非競爭情況性能提升高達 10%。
• Once.Do 在非首次執(zhí)行時（即 once 已經(jīng)被觸發(fā)后）的速度提升了大約 2 倍。

sync.Pool 的改進

sync.Pool 是一個用于存儲和復用臨時對象的技術，主要目的是減少內(nèi)存分配次數(shù)和 GC 壓力，尤其適用于那些需要頻繁創(chuàng)建和銷毀、生命周期短暫的對象（如網(wǎng)絡連接的緩沖區(qū)、編解碼器的狀態(tài)對象等）。

var bufferPool = sync.Pool{
    New: func() interface{} {
        // New 函數(shù)用于在 Pool 為空時創(chuàng)建新對象
        fmt.Println("Allocating new buffer")
        return make([]byte, 4096) // 例如創(chuàng)建一個 4KB 的緩沖區(qū)
    },
}

func handleConnection(conn net.Conn) {
    // 從 Pool 獲取一個 buffer
    buf := bufferPool.Get().([]byte)

    // 使用 buffer ...
    n, err := conn.Read(buf)
    // ...

    // 將 buffer 放回 Pool 以便復用
    // 注意：放回前最好清理一下 buffer 內(nèi)容（如果需要）
    // 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 暫停時間產(chǎn)生比較明顯的影響。Go 1.13 優(yōu)化了 sync.Pool 的內(nèi)部實現(xiàn)，使得即使池中對象很多，對 GC 暫停時間的影響也顯著減小。
• 跨 GC 保留部分對象 ：這是 sync.Pool 行為的一個重大變化。在 Go 1.13 之前， 每次 GC 運行時，sync.Pool 中的所有緩存對象都會被無條件清除 。這意味著每次 GC 之后，如果程序繼續(xù)請求對象，Pool 會變空，導致大量調(diào)用 New 函數(shù)來重新填充緩存，這可能在 GC 后造成短暫的性能抖動（分配和 GC 壓力增加）。

從 Go 1.13 開始，sync.Pool可以在 GC 之后保留一部分之前緩存的對象 。它使用了一個兩階段的緩存機制，主緩存池仍然會在 GC 時被清理，但會有一個備用（受害者）緩存池保留上一次 GC 清理掉的對象，供本次 GC 后使用。這樣，GC 之后 Pool 不再是完全空的，可以更快地提供緩存對象，減少了對 New 的調(diào)用頻率，從而平滑了 GC 后的性能表現(xiàn)，降低了負載峰值。

使用 sync.Pool 的注意事項（結合 1.13 改進）

• sync.Pool 仍然適用于臨時對象的復用，以減少分配和 GC 壓力。
• 由于對象現(xiàn)在可能跨 GC 保留，從 Pool 中 Get 到的對象可能包含上次使用時殘留的數(shù)據(jù)。因此，在使用前對其進行必要的 重置或清理 變得更加重要（例如，對于 []byte，使用 buf = buf[:0]；對于結構體，清零關鍵字段）。
• Pool 保留對象的能力并不意味著你可以用它來管理需要精確生命周期控制的資源（如文件句柄、網(wǎng)絡連接），這些資源通常需要顯式的 Close 方法。
• 雖然跨 GC 保留對象減少了冷啟動開銷，但也意味著 Pool 可能會持有內(nèi)存更長時間。不過，Go 1.13 運行時本身也改進了內(nèi)存歸還給操作系統(tǒng)的策略，這在一定程度上平衡了這一點。

總的來說，Go 1.13 中 sync 包的改進提升了常用同步原語的性能，并使 sync.Pool 在高并發(fā)和頻繁 GC 的場景下表現(xiàn)更加穩(wěn)定和高效。