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

Go 1.17 值得關注的改動：

1. 語言增強： 引入了從 切片（slice） 到數組指針的轉換，并添加了 unsafe.Add 和 unsafe.Slice 以簡化 unsafe.Pointer 的使用。
2. 模塊圖修剪： 對于指定 go 1.17 或更高版本的模塊，go.mod 文件現在包含更全面的傳遞性依賴信息，從而啟用模塊圖修剪和依賴懶加載機制。
3. go run 增強： go run 命令現在支持版本后綴（如 cmd@v1.0.0），允許在模塊感知模式下運行指定版本的包，忽略當前模塊的依賴。
4. Vet 工具更新： 新增了三項檢查，分別針對 //go:build 與 // +build 的一致性、對無緩沖 channel 使用 signal.Notify 的潛在風險，以及 error 類型上 As/Is/Unwrap 方法的簽名規范。
5. 編譯器優化： 在 64 位 x86 架構上實現了新的基于寄存器的函數調用約定，取代了舊的基于棧的約定，帶來了約 5% 的性能提升和約 2% 的二進制體積縮減。

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

Go 1.17 語言層面引入了切片到數組指針的轉換以及 unsafe 包的增強

Go 1.17 在語言層面帶來了三處增強：

• 切片到數組指針的轉換

現在可以將一個 切片（slice） s（類型為 []T）轉換為一個數組指針 a（類型為 *[N]T）。

這種轉換的語法是 (*[N]T)(s)。轉換后的數組指針 a 和原始切片 s 在有效索引范圍內（0 <= i < N）共享相同的底層元素，即 &a[i] == &s[i]。

需要特別注意 ：如果切片 s 的長度 len(s) 小于數組的大小 N，該轉換會在運行時引發 panic。這是 Go 語言中第一個可能在運行時 panic 的類型轉換，依賴于“類型轉換永不 panic”假定的靜態分析工具需要更新以適應這個變化。

package main

import "fmt"

func main() {
    s := []int{1, 2, 3, 4, 5}

    // 成功轉換：切片長度 >= 數組大小
    arrPtr1 := (*[3]int)(s)
    fmt.Printf("arrPtr1: %p, %v\n", arrPtr1, *arrPtr1) // 輸出指針地址和 {1 2 3}
    fmt.Printf("&arrPtr1[0]: %p, &s[0]: %p\n", &arrPtr1[0], &s[0]) // 輸出相同的地址

    arrPtr2 := (*[5]int)(s)
    fmt.Printf("arrPtr2: %p, %v\n", arrPtr2, *arrPtr2) // 輸出指針地址和 {1 2 3 4 5}

    // 修改通過指針訪問的元素，會影響原切片
    arrPtr1[0] = 100
    fmt.Printf("s after modification: %v\n", s) // 輸出 [100 2 3 4 5]

    // 失敗轉換：切片長度 < 數組大小
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r) // 輸出 Recovered from panic: runtime error: cannot convert slice with length 5 to pointer to array with length 6
        }
    }()
    arrPtr3 := (*[6]int)(s) // 這行會引發 panic
    fmt.Println("This line will not be printed", arrPtr3)
}

arrPtr1: 0xc0000b2000, [1 2 3]
&arrPtr1[0]: 0xc0000b2000, &s[0]: 0xc0000b2000
arrPtr2: 0xc0000b2000, [1 2 3 4 5]
s after modification: [100 2 3 4 5]
Recovered from panic: runtime error: cannot convert slice with length 5 to pointer to array with length 6

• unsafe.Add 函數

unsafe 包新增了 Add 函數：unsafe.Add(ptr unsafe.Pointer, len IntegerType) unsafe.Pointer。

它的作用是將一個非負的整數 len（必須是整數類型，如 int, uintptr 等）加到 ptr 指針上，并返回更新后的指針。其效果等價于 unsafe.Pointer(uintptr(ptr) + uintptr(len))，但意圖更清晰，且有助于靜態分析工具理解指針運算。

這個函數的目的是為了簡化遵循 unsafe.Pointer 安全規則的代碼編寫，但它 并沒有改變 這些規則。使用 unsafe.Add 仍然需要確保結果指針指向的是合法的內存分配。

例如，在沒有 unsafe.Add 之前，如果要訪問結構體中某個字段的地址，可能需要這樣做：

package main

import (
    "fmt"
    "unsafe"
)

type MyStruct struct {
    A int32
    B float64 // B 相對于結構體起始地址的偏移量是 8 (在 64 位系統上，int32 占 4 字節，需要 4 字節對齊填充)
}

func main() {
    data := MyStruct{A: 1, B: 3.14}
    ptr := unsafe.Pointer(&data)

    // 舊方法：使用 uintptr 進行計算
    offsetB_old := unsafe.Offsetof(data.B) // 獲取字段 B 的偏移量，類型為 uintptr
    ptrB_old := unsafe.Pointer(uintptr(ptr) + offsetB_old)
    *(*float64)(ptrB_old) = 6.28 // 修改 B 的值

    fmt.Println("Old method result:", data)

    // 新方法：使用 unsafe.Add
    data = MyStruct{A: 1, B: 3.14} // 重置數據
    ptr = unsafe.Pointer(&data)
    offsetB_new := unsafe.Offsetof(data.B)
    ptrB_new := unsafe.Add(ptr, offsetB_new) // 使用 unsafe.Add 進行指針偏移
    *(*float64)(ptrB_new) = 9.42             // 修改 B 的值

    fmt.Println("New method result:", data)
}

雖然效果相同，但 unsafe.Add 更明確地表達了“指針加偏移量”的意圖。

• unsafe.Slice 函數

unsafe 包新增了 Slice 函數：unsafe.Slice(ptr *T, len IntegerType) []T。

對于一個類型為 *T 的指針 ptr 和一個非負整數 len，unsafe.Slice(ptr, len) 會返回一個類型為 []T 的切片。這個切片的底層數組從 ptr 指向的地址開始，其長度（length）和容量（capacity）都等于 len。

同樣，這個函數的目的是簡化遵循 unsafe.Pointer 安全規則的代碼，尤其是從一個指針和長度創建切片時，避免了之前需要構造 reflect.SliceHeader 或 reflect.StringHeader 的復雜步驟，但規則本身不變。使用者必須保證 ptr 指向的內存區域至少包含 len * unsafe.Sizeof(T) 個字節，并且這塊內存在切片的生命周期內是有效的。

例如，從一個 C 函數返回的指針和長度創建 Go 切片：

package main

/*
#include <stdlib.h>

int create_int_array(int size, int** out_ptr) {
    int* arr = (int*)malloc(size * sizeof(int));
    if (arr == NULL) {
        *out_ptr = NULL;
        return 0;
    }
    for (int i = 0; i < size; i++) {
        arr[i] = i * 10;
    }
    *out_ptr = arr;
    return size;
}
*/
import "C"
import (
    "fmt"
    "unsafe"
)

func main() {
    var cPtr *C.int
    cSize := C.create_int_array(5, &cPtr)
    defer C.free(unsafe.Pointer(cPtr)) // 必須記得釋放 C 分配的內存

    if cPtr == nil {
        fmt.Println("Failed to allocate C memory")
        return
    }

    // 使用 unsafe.Slice 創建 Go 切片
    // 注意：這里的 cSize 類型是 C.int，需要轉換為 Go 的整數類型 int32
    goSlice := unsafe.Slice((*int32)(unsafe.Pointer(cPtr)), int(cSize))

    fmt.Printf("Go slice: %v, len=%d, cap=%d\n", goSlice, len(goSlice), cap(goSlice))
    // 輸出: Go slice: [0 10 20 30 40], len=5, cap=5

    // 可以像普通 Go 切片一樣使用
    goSlice[0] = 100
    fmt.Printf("Modified C data via Go slice: %d\n", *cPtr) // 輸出: Modified C data via Go slice: 100
}

piperliu@go-x86:~/code/playground$ go env | grep CGO
GCCGO="gccgo"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
piperliu@go-x86:~/code/playground$ go run main.go 
Go slice: [0 10 20 30 40], len=5, cap=5
Modified C data via Go slice: 100

使用 unsafe.Slice 比手動設置 SliceHeader 更簡潔且不易出錯。

總的來說，unsafe 包的這兩個新函數是為了讓開發者在需要進行底層操作時，能夠更容易地編寫出符合 unsafe.Pointer 安全約定的代碼，而不是放寬這些約定。

Go 1.17 模塊管理與 go 命令的諸多改進

Go 1.17 對 Go 命令及其模塊管理機制進行了多項重要改進，核心目標是提升構建性能、依賴管理的準確性和用戶體驗。

1. 模塊圖修剪 (Module Graph Pruning) 與 依賴懶加載 (Lazy Loading)

• 之前行為 ：當構建一個模塊時，Go 命令需要加載該模塊所有直接和間接依賴的 go.mod 文件，構建一個完整的 模塊依賴圖（module dependency graph）。即使某些間接依賴對于當前構建并非必需，它們的 go.mod 文件也可能被下載和解析。
• Go 1.17 行為 (go 1.17 或更高)

go.mod 文件內容變化 ：如果一個模塊在其 go.mod 文件中聲明 go 1.17 或更高版本，運行 go mod tidy 時，go.mod 文件會包含更詳細的傳遞性依賴信息。具體來說，它會為 每一個 提供了被主模塊（main module）傳遞性導入（transitively-imported）的包的模塊添加顯式的 require 指令。這些新增的間接依賴通常會放在一個單獨的 require 塊中，以區別于直接依賴。

模塊圖修剪 ：有了更完整的依賴信息后，當 Go 命令處理一個 go 1.17 模塊時，其構建的模塊圖可以被“修剪”。對于其他同樣聲明了 go 1.17 或更高版本的依賴模塊，Go 命令只需要考慮它們的 直接 依賴，而不需要遞歸地探索它們的完整傳遞性依賴。

懶加載 ：由于 go.mod 文件包含了構建所需的所有依賴信息，Go 命令現在可以實行 懶加載 。它不再需要讀取（甚至下載）那些對于完成當前命令并非必需的依賴項的 go.mod 文件。

• 示例理解 ：假設你的項目 A 依賴 B (go 1.17)，B 依賴 C (go 1.17)，A 直接導入了 B 中的包，間接導入了 C 中的包。
• 在 Go 1.16 中，A 的 go.mod 可能只寫 require B version。Go 命令會加載 A, B, C 的 go.mod。
• 在 Go 1.17 中，運行 go mod tidy 后，A 的 go.mod 會包含 require B version 和 require C version（在間接依賴塊）。當處理 A 時，Go 命令看到 B 和 C 都是 go 1.17 模塊，并且 A 的 go.mod 已包含所需信息，可能就不再需要去下載和解析 B 或 C 的 go.mod 文件了。
• 設計理念 ：提高構建性能（減少文件下載和解析），提高依賴解析的準確性和穩定性。
• 實踐 ：
• 升級現有模塊：go mod tidy -go=1.17
• 保持與舊版本兼容：默認 go mod tidy 會保留 Go 1.16 需要的 go.sum 條目。
• 僅為 Go 1.17 整理：go mod tidy -compat=1.17 （舊版 Go 可能無法使用此模塊）。
• 查看特定版本的圖：go mod graph -go=1.16。

2. 模塊棄用注釋 (Module Deprecation Comments)

• 之前行為 ：沒有標準的機制來標記一個模塊版本已被棄用。
• Go 1.17 行為 ：模塊作者可以在 go.mod 文件頂部添加 // Deprecated: 棄用信息 格式的注釋，然后發布一個包含此注釋的新版本。
• 效果 ：

go get ：如果需要構建的包依賴了被棄用的模塊，會打印警告。

go list -m -u ：會顯示所有依賴的棄用信息（使用 -f 或 -json 查看完整消息）。

• 示例 ：

// Deprecated: use example.com/mymodule/v2 instead. See migration guide at ...
module example.com/mymodule

go 1.17

require (...)

• 設計理念 ：為模塊維護者提供一個標準化的方式，向用戶傳達模塊狀態和遷移建議（例如，遷移到新的主版本 V2）。

1.go get 行為調整

• -insecure 標志移除 ：該標志已被廢棄和移除。應使用環境變量 GOINSECURE 來允許不安全的協議，使用 GOPRIVATE 或 GONOSUMDB 來跳過校驗和驗證。
• 安裝命令推薦 go install ：使用 go get 安裝命令（即不帶 -d 標志）現在會產生棄用警告。推薦使用 go install cmd@version（如 go install example.com/cmd@latest 或 go install example.com/cmd@v1.2.3）來安裝可執行文件。在 Go 1.18 中，go get 將只用于管理 go.mod 中的依賴。
• 示例 ：安裝最新的 stringer 工具

go install golang.org/x/tools/cmd/stringer@latest

• 設計理念 ：明確區分 go get（管理依賴）和 go install（安裝命令/二進制文件）的職責。提高安全性配置的清晰度。

2.處理缺少 go 指令的 go.mod 文件

• 主模塊 go.mod ：如果主模塊的 go.mod 沒有 go 指令且 Go 命令無法更新它，現在假定為 go 1.11（之前是當前 Go 版本）。
• 依賴模塊 ：如果依賴模塊沒有 go.mod 文件（GOPATH 模式開發）或其 go.mod 文件沒有 go 指令，現在假定為 go 1.16（之前是當前 Go 版本）。
• 設計理念 ：為缺失版本信息的舊代碼提供更穩定和可預測的行為。

2. vendor 目錄內容調整 (go 1.17 或更高)

• vendor/modules.txt ：go mod vendor 現在會在 vendor/modules.txt 中記錄每個 vendored 模塊在其自身 go.mod 中指定的 go 版本。這個版本信息會在從 vendor 構建時使用。
• 移除 go.mod/go.sum ：go mod vendor 現在會省略 vendored 依賴目錄下的 go.mod 和 go.sum 文件，因為它們可能干擾 Go 命令在 vendor 樹內部正確識別模塊根。
• 設計理念 ：確保使用 vendor 構建時能應用正確的語言版本特性，并避免路徑解析問題。

3. 密碼提示抑制

• 使用 SSH 拉取 Git 倉庫時，Go 命令現在默認禁止彈出 SSH 密碼輸入提示和 Git Credential Manager 提示（之前已對其他 Git 密碼提示這樣做）。建議使用 ssh-agent 進行密碼保護的 SSH 密鑰認證。
• 設計理念：提高在自動化環境（如 CI/CD）中使用 Go 命令的便利性和安全性。

4. go mod download (無參數)

• 不帶參數調用 go mod download 時，不再將下載內容的校驗和保存到 go.sum（恢復到 Go 1.15 的行為）。要保存所有模塊的校驗和，請使用 go mod download all。
• 設計理念：減少無參數 go mod download 對 go.sum 的意外修改。

5. //go:build 構建約束 (Build Constraints)

• 新語法引入 ：Go 命令現在理解新的 //go:build 構建約束行，并 優先于 舊的 // +build 行。新語法使用類似 Go 的布爾表達式（如 //go:build linux && amd64 或 //go:build !windows），更易讀寫，不易出錯。
• 過渡與同步 ：目前兩個語法都支持。gofmt 工具現在會自動同步同一文件中的 //go:build 和 // +build 行，確保它們的邏輯一致。建議所有 Go 文件都更新為同時包含兩種形式，并保持同步。
• 示例

// 舊語法
// +build linux darwin

// 新語法 (由 gofmt 自動添加或同步)
//go:build linux || darwin

package mypkg

// 舊語法
// +build !windows,!plan9

// 新語法
//go:build !windows && !plan9

package mypkg

• 設計理念 ：引入一種更現代、更清晰、更不易出錯的構建約束語法，并提供平滑的遷移路徑。

總結與最佳實踐 ： Go 1.17 在模塊管理方面帶來了顯著的性能和健壯性改進。最佳實踐包括：

• 使用 go mod tidy -go=1.17 將項目升級到新的模塊管理機制。
• 使用 go install cmd@version 來安裝和運行特定版本的 Go 程序。
• 開始采用 //go:build 語法，并利用 gofmt 來保持與舊語法的同步。
• 棄用模塊時，使用 // Deprecated: 注釋。
• 使用環境變量（GOINSECURE, GOPRIVATE, GONOSUMDB）替代 -insecure 標志。
• 理解 go.mod 中新的間接依賴 require 塊的含義。

這些改動共同體現了 Go 團隊持續優化開發者體驗、構建性能和依賴管理可靠性的設計理念。

go run 在 Go 1.17 中獲得了在模塊感知模式下運行指定版本包的能力

在 Go 1.17 之前，go run 命令主要用于快速編譯和運行當前目錄或指定 Go 源文件。如果在一個模塊目錄下運行，它會使用當前模塊的依賴；如果在模塊之外，它可能工作在 GOPATH 模式下。要想運行一個特定版本的、非當前模塊依賴的 Go 程序，通常需要先用 go get（可能會修改當前 go.mod 或安裝到 GOPATH）或者 go install 來獲取對應版本的源碼或編譯好的二進制文件。

Go 1.17 對 go run 進行了增強，允許直接運行指定版本的包，即使這個包不在當前模塊的依賴中，也不會修改當前模塊的 go.mod 文件。

新特性 ：go run 命令現在接受帶有版本后綴的包路徑參數，例如 example.com/cmd@v1.0.0 或 example.com/cmd@latest。

行為 ： 當使用這種帶版本后綴的語法時，go run 會：

1. 在模塊感知模式下運行 ：它會像處理模塊依賴一樣去查找和下載指定版本的包及其依賴。
2. 忽略當前目錄的 go.mod ：它不會使用當前項目（如果在項目目錄下運行）的 go.mod 文件來解析依賴，而是為這個臨時的運行任務構建一個獨立的依賴集。
3. 不安裝 ：它只編譯并運行程序，不會將編譯結果安裝到 GOPATH/bin 或 GOBIN。
4. 不修改當前 go.mod ：當前項目的 go.mod 和 go.sum 文件不會被這次 go run 操作修改。

這個特性非常適合以下情況：

• 臨時運行特定版本的工具 ：比如，你想用最新版本的 stringer 工具生成代碼，但你的項目依賴的是舊版本。
• 在 CI/CD 或腳本中運行工具 ：無需先 go install，可以直接 go run 指定版本的構建工具或代碼生成器。
• 測試不同版本的命令 ：快速嘗試一個庫提供的命令的不同版本，而無需切換項目依賴。

示例 ：

假設你想運行 golang.org/x/tools/cmd/stringer 的最新版本來為當前目錄下的 mytype.go 文件中的 MyType 生成代碼，但你的項目 go.mod 可能沒有依賴它，或者依賴了舊版。

# 使用 Go 1.17 的 go run 運行最新版的 stringer
go run golang.org/x/tools/cmd/stringer@latest -type=MyType

# 運行特定版本的內部工具，不影響當前項目依賴
go run mycompany.com/tools/deploy-tool@v1.2.3 --config=staging.yaml

這避免了先 go get golang.org/x/tools/cmd/stringer（可能污染 go.mod 或全局 GOPATH）或者 go install golang.org/x/tools/cmd/stringer@latest（需要寫入 GOBIN）的步驟。

設計理念 ：提升 go run 的靈活性和便利性，使其成為一個更強大的臨時執行 Go 程序的工具，特別是在需要版本控制和隔離依賴的場景下。

Go 1.17 的 vet 工具增加了對構建標簽、信號處理和錯誤接口方法簽名的靜態檢查

Go 1.17 版本中的 go vet 工具（一個用于發現 Go 代碼中潛在錯誤的靜態分析工具）新增了三項有用的檢查，旨在幫助開發者避免一些常見的陷阱和錯誤。

1. 檢查不匹配的 //go:build 和 // +build 行

• 背景 ：Go 1.17 正式引入了新的 //go:build 構建約束語法，并推薦使用它替代舊的 // +build 語法。在過渡期間，推薦兩者并存且保持邏輯一致。
• 問題 ：如果開發者手動修改了其中一個，或者放置的位置不正確（比如 //go:build 必須在文件頂部，僅前面可以有空行或注釋），可能會導致兩個約束的實際效果不一致，根據使用的 Go 版本不同，編譯結果可能出乎意料。
• Vet 檢查 ：vet 現在會驗證同一個文件中的 //go:build 和 // +build 行是否位于正確的位置，并且它們的邏輯含義是否同步。
• 修復 ：如果檢查出不一致，可以使用 gofmt 工具自動修復，它會根據 //go:build 的邏輯（如果存在）來同步 // +build，或者反之。
• 示例 ：

// BAD: Logic mismatch
//go:build linux && amd64
// +build linux,arm64  <-- Vet will warn about this mismatch

package main

• 為何升級 ：確保在向新的 //go:build 語法遷移的過程中，代碼行為保持一致，減少因構建約束不匹配導致的潛在錯誤。

1. 警告對無緩沖通道調用 signal.Notify

• 背景 ：os/signal.Notify 函數用于將指定的操作系統信號轉發到提供的 channel 中。
• 問題 ：signal.Notify 在發送信號到 channel 時是 非阻塞 的。如果提供的 channel 是無緩沖的 (make(chan os.Signal))，并且在信號到達時沒有 goroutine 正在等待從該 channel 接收 (<-c)，那么 signal.Notify 的發送操作會失敗，這個信號就會被 丟棄 。這可能導致程序無法響應重要的 OS 信號（如 SIGINT (Ctrl+C), SIGTERM 等）。
• Vet 檢查 ：vet 現在會警告那些將無緩沖 channel 作為參數傳遞給 signal.Notify 的調用。
• 修復 ：應該使用帶有足夠緩沖區的 channel，至少為 1，以確保即使接收者暫時阻塞，信號也能被緩存而不會丟失。
• 示例

package main

import (
    "fmt"
    "os"
    "os/signal"
    "time"
)

func main() {
    // BAD: Unbuffered channel - Vet will warn here
    cBad := make(chan os.Signal)
    signal.Notify(cBad, os.Interrupt) // Sending os.Interrupt (Ctrl+C) to cBad

    go func() {
        // Simulate receiver being busy for a moment
        time.Sleep(1 * time.Second)
        sig := <-cBad // Might miss signal if it arrives during sleep
        fmt.Println("Received signal (bad):", sig)
    }()

    fmt.Println("Send Ctrl+C within 1 second (bad example)...")
    time.Sleep(5 * time.Second) // Wait long enough


    // GOOD: Buffered channel
    cGood := make(chan os.Signal, 1) // Buffer size of 1 is usually sufficient
    signal.Notify(cGood, os.Interrupt)

    go func() {
        sig := <-cGood // Signal will be buffered if it arrives while this goroutine isn't ready
        fmt.Println("Received signal (good):", sig)
    }()

    fmt.Println("Send Ctrl+C (good example)...")
    time.Sleep(5 * time.Second)
}

• 為何升級 ：提高信號處理的可靠性，防止因通道無緩沖導致的關鍵信號丟失，這種 bug 通常難以復現和調試。

1. 警告 error 類型上 Is, As, Unwrap 方法的簽名錯誤

• 背景 ：Go 1.13 引入了 errors 包的 Is, As, Unwrap 函數，它們允許錯誤類型提供特定的方法來自定義錯誤鏈的檢查、類型斷言和解包行為。這些函數依賴于被檢查的 error 值（或其鏈中的錯誤）實現了特定簽名的方法：

errors.Is 查找 Is(error) bool 方法。

errors.As 查找 As(interface{}) bool 方法（注意參數是 interface{}，通常寫成 any）。

errors.Unwrap 查找 Unwrap() error 方法。

• 問題 ：如果開發者在自己的 error 類型上定義了名為 Is, As, 或 Unwrap 的方法，但方法簽名與 errors 包期望的不匹配（例如，把 Is(error) bool 寫成了 Is(target interface{}) bool），那么 errors 包的相應函數（如 errors.Is）會 忽略 這個用戶定義的方法，導致其行為不符合預期。開發者可能以為自己定制了 Is 的行為，但實際上沒有生效。
• Vet 檢查 ：vet 現在會檢查實現了 error 接口的類型。如果這些類型上有名為 Is, As, 或 Unwrap 的方法，vet 會驗證它們的簽名是否符合 errors 包的預期。如果不符合，則發出警告。
• 修復 ：確保自定義的 Is, As, Unwrap 方法簽名與 errors 包的要求完全一致。
• 示例

package main

import (
    "errors"
    "fmt"
)

// Define a target error
var ErrTarget = errors.New("target error")

// BAD: Incorrect Is signature (should be Is(error) bool) - Vet will warn here
type MyErrorBad struct{ msg string }
func (e MyErrorBad) Error() string { return e.msg }
func (e MyErrorBad) Is(target interface{}) bool { // Incorrect signature!
    fmt.Println("MyErrorBad.Is(interface{}) called") // This won't be called by errors.Is
    if t, ok := target.(error); ok {
        return t == ErrTarget
    }
    return false
}

// GOOD: Correct Is signature
type MyErrorGood struct{ msg string }
func (e MyErrorGood) Error() string { return e.msg }
func (e MyErrorGood) Is(target error) bool { // Correct signature!
    fmt.Println("MyErrorGood.Is(error) called")
    return target == ErrTarget
}

func main() {
    errBad := MyErrorBad{"bad error"}
    errGood := MyErrorGood{"good error"}

    fmt.Println("Checking errBad against ErrTarget:")
    // errors.Is finds no `Is(error) bool` method on errBad.
    // It falls back to checking if errBad == ErrTarget, which is false.
    // The custom MyErrorBad.Is(interface{}) is NOT called.
    if errors.Is(errBad, ErrTarget) {
        fmt.Println("  errBad IS ErrTarget (unexpected)")
    } else {
        fmt.Println("  errBad IS NOT ErrTarget (as expected, but custom Is ignored)")
    }

    fmt.Println("\nChecking errGood against ErrTarget:")
    // errors.Is finds the correctly signed `Is(error) bool` method on errGood.
    // It calls errGood.Is(ErrTarget).
    if errors.Is(errGood, ErrTarget) {
        fmt.Println("  errGood IS ErrTarget (as expected, custom Is called)")
    } else {
        fmt.Println("  errGood IS NOT ErrTarget (unexpected)")
    }
}

Checking errBad against ErrTarget:
  errBad IS NOT ErrTarget (as expected, but custom Is ignored)

Checking errGood against ErrTarget:
MyErrorGood.Is(error) called
  errGood IS ErrTarget (as expected, custom Is called)

• 為何升級 ：確保開發者在嘗試利用 Go 的錯誤處理增強特性（Is/As/Unwrap）時，能夠正確地實現接口契約，避免因簽名錯誤導致的功能不生效和潛在的邏輯錯誤。

Go 1.17 編譯器引入基于寄存器的調用約定及其他優化

Go 1.17 的編譯器帶來了一項重要的底層優化和幾項相關改進，旨在提升程序性能和開發者體驗。

1. 基于寄存器的函數調用約定 (Register-based Calling Convention)

• 背景 ：在 Go 1.17 之前，函數調用時，參數和返回值通常是通過內存棧（stack）來傳遞的。這涉及到內存讀寫操作，相對較慢。
• Go 1.17 變化 ：在特定的架構上，Go 1.17 實現了一種新的函數調用約定，優先使用 CPU 寄存器 (registers) 來傳遞函數參數和結果。寄存器是 CPU 內部的高速存儲單元，訪問速度遠快于內存。
• 適用范圍 ：這個新約定目前在 64 位 x86 架構 ( amd64 ) 上的 Linux (linux/amd64)、 macOS (darwin/amd64) 和 Windows (windows/amd64) 平臺啟用。
• 主要影響 ：

性能提升：根據官方對代表性 Go 包和程序的基準測試，這項改動帶來了大約 5% 的性能提升 。

二進制大小縮減 ：由于減少了棧操作相關的指令，編譯出的二進制文件大小通常會 減少約 2% 。

• 兼容性 ：
• 安全 (Safe) Go 代碼 ：這項變更 不影響 任何遵守 Go 語言規范的安全代碼的功能。
• unsafe 代碼 ：如果代碼違反了 unsafe.Pointer 的規則來訪問函數參數，或者依賴于比較函數代碼指針等未文檔化的行為，可能會受到影響。
• 匯編 (Assembly) 代碼 ：設計上對大多數匯編代碼 沒有影響 。為了保持與現有匯編函數的兼容性（它們可能仍使用基于棧的約定），編譯器會自動生成 適配器函數 (adapter functions) 。這些適配器負責在新的寄存器約定和舊的棧約定之間進行轉換。
• 適配器的可見性 ：適配器通常對用戶是透明的。但有一個例外：如果 在匯編代碼中獲取 Go 函數的地址 ，或者 在 Go 代碼中使用 reflect.ValueOf(fn).Pointer() 或 unsafe.Pointer 獲取匯編函數的地址 ，現在獲取到的可能是適配器的地址，而不是原始函數的地址。依賴這些代碼指針精確值的代碼可能不再按預期工作。
• 輕微性能開銷 ：在兩種情況下，適配器可能引入非常小的性能開銷：一是通過函數值（func value）間接調用匯編函數；二是從匯編代碼調用 Go 函數。
• 圖示（概念性） ：

// 舊：基于棧的調用約定 (簡化)
+-----------------+ <-- Higher memory addresses
| Caller's frame  |
+-----------------+
| Return Address  |
+-----------------+
| Return Value(s) | <--- Space reserved on stack
+-----------------+
| Argument N      | <--- Pushed onto stack
+-----------------+
| ...             |
+-----------------+
| Argument 1      | <--- Pushed onto stack
+-----------------+ --- Stack Pointer (SP) before call
| Callee's frame  |
+-----------------+ <-- Lower memory addresses

// 新：基于寄存器的調用約定 (簡化, amd64)
CPU Registers:
RAX, RBX, RCX, RDI, RSI, R8-R15, XMM0-XMM14 etc. used for integer, pointer, float args/results

Stack: (Used only if args don't fit in registers, or for certain types)
+-----------------+ <-- Higher memory addresses
| Caller's frame  |
+-----------------+
| Return Address  |
+-----------------+
| Stack Argument M| <--- If needed
+-----------------+
| ...             |
+-----------------+ --- Stack Pointer (SP) before call
| Callee's frame  |
+-----------------+ <-- Lower memory addresses

• 為何升級 ：核心目的是 提升性能 。通過利用現代 CPU 架構中快速的寄存器，減少內存訪問，從而加快函數調用的速度。這也是許多其他編譯型語言（如 C/C++）采用的優化策略。

1. 改進的棧跟蹤信息 (Stack Traces)

• 背景 ：當發生未捕獲的 panic 或調用 runtime.Stack 時，Go 運行時會打印棧跟蹤信息，用于調試。
• 之前格式 ：函數參數通常以其在內存布局中的原始十六進制字形式打印，可讀性較差，尤其對于復合類型。返回值也可能被打印，但通常不準確。
• Go 1.17 格式 ：

參數打印 ：現在會 分別打印 源代碼中聲明的每個參數，用逗號分隔。聚合類型（結構體 struct、數組 array、字符串 string、切片 slice、接口 interface、復數 complex）的參數會用花括號 {} 界定。這大大提高了可讀性。

返回值 ：不再打印通常不準確的函數返回值。

注意事項 ：如果一個參數只存在于寄存器中，并且在生成棧跟蹤時沒有被存儲到內存（spilled to memory），那么打印出的該參數的值可能 不準確 。

• 為何升級 ：提升 panic 和 runtime.Stack 輸出信息的可讀性，讓開發者更容易理解程序崩潰或特定時間點的函數調用狀態。

2. 允許內聯包含閉包的函數 (Inlining Closures)

• 背景 ：內聯 (Inlining) 是一種編譯器優化，它將函數調用替換為函數體的實際代碼，以減少函數調用的開銷。閉包 (Closure) 是指引用了其外部作用域變量的函數。
• 之前行為 ：通常，包含閉包的函數不會被編譯器內聯。
• Go 1.17 行為 ：編譯器現在 可以 內聯包含閉包的函數了。
• 潛在影響 ：

性能 ：可能帶來性能提升，因為減少了函數調用開銷。

代碼指針 ：一個副作用是，如果一個帶閉包的函數在多個地方被內聯，每次內聯可能會產生一個 不同的閉包代碼指針 。Go 語言本身不允許直接比較函數值。但如果代碼使用 reflect 或 unsafe.Pointer 繞過這個限制來比較函數（這本身就是不推薦的做法），那么這種行為可能會暴露這類代碼中的潛在 bug，因為之前認為相同的函數現在可能因為內聯而具有不同的代碼指針。

• 為何升級 ：擴展編譯器的優化能力，讓更多函數（包括帶閉包的）能夠受益于內聯優化，從而提升程序性能。

Go 1.17 編譯器在 amd64 平臺上的核心變化是引入了基于寄存器的調用約定，顯著提升了性能。同時，改進了棧跟蹤的可讀性，并擴大了內聯優化的范圍。這些改動對大多數開發者是透明的，但使用 unsafe 或依賴底層細節（如函數指針比較）的代碼需要注意可能的變化。