Go 1.17 相比 Go 1.16 有哪些值得注意的改动？-阿南达文事网

Go 1.17 相比 Go 1.16 有哪些值得注意的改动？

本系列旨在梳理 Go 的 release notes 与发展史，来更加深入地理解 Go 语言设计的思路。

/doc/go1.17

Go 1.17 值得关注的改动：

语言增强：引入了从切片（slice）到数组指针的转换，并添加了 unsafe.Add 和 unsafe.Slice 以简化 unsafe.Pointer 的使用。
模块图修剪：对于指定 go 1.17 或更高版本的模块，go.mod 文件现在包含更全面的传递性依赖信息，从而启用模块图修剪和依赖懒加载机制。
go run 增强： go run 命令现在支持版本后缀（如 cmd@v1.0.0），允许在模块感知模式下运行指定版本的包，忽略当前模块的依赖。
Vet 工具更新：新增了三项检查，分别针对 //go:build 与 // +build 的一致性、对无缓冲 channel 使用 signal.Notify 的潜在风险，以及 error 类型上 As/Is/Unwrap 方法的签名规范。
编译器优化：在 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”假定的静态分析工具需要更新以适应这个变化。

代码语言：go复制

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)
}

代码语言：txt复制

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 之前，如果要访问结构体中某个字段的地址，可能需要这样做：

代码语言：go复制

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 切片：

代码语言：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
}

代码语言：bash复制

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 命令及其模块管理机制进行了多项重要改进，核心目标是提升构建性能、依赖管理的准确性和用户体验。

模块图修剪 (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。

模块弃用注释 (Module Deprecation Comments)

之前行为 ：没有标准的机制来标记一个模块版本已被弃用。
Go 1.17 行为 ：模块作者可以在 go.mod 文件顶部添加 // Deprecated: 弃用信息 格式的注释，然后发布一个包含此注释的新版本。
效果：
- go get ：如果需要构建的包依赖了被弃用的模块，会打印警告。
- go list -m -u ：会显示所有依赖的弃用信息（使用 -f 或 -json 查看完整消息）。
示例：

代码语言：go复制

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

go 1.17

require (...)

设计理念 ：为模块维护者提供一个标准化的方式，向用户传达模块状态和迁移建议（例如，迁移到新的主版本 V2）。

go get 行为调整

-insecure 标志移除 ：该标志已被废弃和移除。应使用环境变量 GOINSECURE 来允许不安全的协议，使用 GOPRIVATE 或 GONOSUMDB 来跳过校验和验证。
安装命令推荐 go install ：使用 go get 安装命令（即不带 -d 标志）现在会产生弃用警告。推荐使用 go install cmd@version（如 go install example/cmd@latest 或 go install example/cmd@v1.2.3）来安装可执行文件。在 Go 1.18 中，go get 将只用于管理 go.mod 中的依赖。
示例：安装最新的 stringer 工具

代码语言：bash复制

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

设计理念 ：明确区分 go get（管理依赖）和 go install（安装命令/二进制文件）的职责。提高安全性配置的清晰度。

处理缺少 go 指令的 go.mod 文件

主模块 go.mod ：如果主模块的 go.mod 没有 go 指令且 Go 命令无法更新它，现在假定为 go 1.11（之前是当前 Go 版本）。
依赖模块 ：如果依赖模块没有 go.mod 文件（GOPATH 模式开发）或其 go.mod 文件没有 go 指令，现在假定为 go 1.16（之前是当前 Go 版本）。
设计理念 ：为缺失版本信息的旧代码提供更稳定和可预测的行为。

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 构建时能应用正确的语言版本特性，并避免路径解析问题。

密码提示抑制

使用 SSH 拉取 Git 仓库时，Go 命令现在默认禁止弹出 SSH 密码输入提示和 Git Credential Manager 提示（之前已对其他 Git 密码提示这样做）。建议使用 ssh-agent 进行密码保护的 SSH 密钥认证。
设计理念：提高在自动化环境（如 CI/CD）中使用 Go 命令的便利性和安全性。

go mod download (无参数)

不带参数调用 go mod download 时，不再将下载内容的校验和保存到 go.sum（恢复到 Go 1.15 的行为）。要保存所有模块的校验和，请使用 go mod download all。
设计理念：减少无参数 go mod download 对 go.sum 的意外修改。

//go:build 构建约束 (Build Constraints)

新语法引入 ：Go 命令现在理解新的 //go:build 构建约束行，并 优先于 旧的 // +build 行。新语法使用类似 Go 的布尔表达式（如 //go:build linux && amd64 或 //go:build !windows），更易读写，不易出错。
过渡与同步 ：目前两个语法都支持。gofmt 工具现在会自动同步同一文件中的 //go:build 和 // +build 行，确保它们的逻辑一致。建议所有 Go 文件都更新为同时包含两种形式，并保持同步。
示例

代码语言：go复制

// 旧语法
// +build linux darwin

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

package mypkg

代码语言：go复制

// 旧语法
// +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/cmd@v1.0.0 或 example/cmd@latest。

行为：

当使用这种带版本后缀的语法时，go run 会：

在模块感知模式下运行 ：它会像处理模块依赖一样去查找和下载指定版本的包及其依赖。
忽略当前目录的 go.mod ：它不会使用当前项目（如果在项目目录下运行）的 go.mod 文件来解析依赖，而是为这个临时的运行任务构建一个独立的依赖集。
不安装 ：它只编译并运行程序，不会将编译结果安装到 GOPATH/bin 或 GOBIN。
不修改当前 go.mod ：当前项目的 go.mod 和 go.sum 文件不会被这次 go run 操作修改。

这个特性非常适合以下情况：

临时运行特定版本的工具 ：比如，你想用最新版本的 stringer 工具生成代码，但你的项目依赖的是旧版本。
在 CI/CD 或脚本中运行工具 ：无需先 go install，可以直接 go run 指定版本的构建工具或代码生成器。
测试不同版本的命令 ：快速尝试一个库提供的命令的不同版本，而无需切换项目依赖。

示例：

假设你想运行 golang/x/tools/cmd/stringer 的最新版本来为当前目录下的 mytype.go 文件中的 MyType 生成代码，但你的项目 go.mod 可能没有依赖它，或者依赖了旧版。

代码语言：bash复制

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

# 运行特定版本的内部工具，不影响当前项目依赖
go run mycompany/tools/deploy-tool@v1.2.3 --config=staging.yaml

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

设计理念 ：提升 go run 的灵活性和便利性，使其成为一个更强大的临时执行 Go 程序的工具，特别是在需要版本控制和隔离依赖的场景下。

Go 1.17 的 `vet` 工具增加了对构建标签、信号处理和错误接口方法签名的静态检查

Go 1.17 版本中的 go vet 工具（一个用于发现 Go 代码中潜在错误的静态分析工具）新增了三项有用的检查，旨在帮助开发者避免一些常见的陷阱和错误。

检查不匹配的 //go:build 和 // +build 行

背景：Go 1.17 正式引入了新的 //go:build 构建约束语法，并推荐使用它替代旧的 // +build 语法。在过渡期间，推荐两者并存且保持逻辑一致。
问题：如果开发者手动修改了其中一个，或者放置的位置不正确（比如 //go:build 必须在文件顶部，仅前面可以有空行或注释），可能会导致两个约束的实际效果不一致，根据使用的 Go 版本不同，编译结果可能出乎意料。
Vet 检查 ：vet 现在会验证同一个文件中的 //go:build 和 // +build 行是否位于正确的位置，并且它们的逻辑含义是否同步。
修复：如果检查出不一致，可以使用 gofmt 工具自动修复，它会根据 //go:build 的逻辑（如果存在）来同步 // +build，或者反之。
示例：

代码语言：go复制

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

package main

为何升级 ：确保在向新的 //go:build 语法迁移的过程中，代码行为保持一致，减少因构建约束不匹配导致的潜在错误。

警告对无缓冲通道调用 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，以确保即使接收者暂时阻塞，信号也能被缓存而不会丢失。
示例

代码语言：go复制

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 通常难以复现和调试。

警告 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 包的要求完全一致。
示例

代码语言：go复制

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)")
    }
}

代码语言：bash复制

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 的编译器带来了一项重要的底层优化和几项相关改进，旨在提升程序性能和开发者体验。

基于寄存器的函数调用约定 (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 函数。
图示（概念性） ：

代码语言：txt复制

// 旧：基于栈的调用约定 (简化)
+-----------------+ <-- 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++）采用的优化策略。

改进的栈跟踪信息 (Stack Traces)

背景：当发生未捕获的 panic 或调用 runtime.Stack 时，Go 运行时会打印栈跟踪信息，用于调试。
之前格式 ：函数参数通常以其在内存布局中的原始十六进制字形式打印，可读性较差，尤其对于复合类型。返回值也可能被打印，但通常不准确。
Go 1.17 格式 ：
- 参数打印 ：现在会 分别打印 源代码中声明的每个参数，用逗号分隔。聚合类型（结构体 struct、数组 array、字符串 string、切片 slice、接口 interface、复数 complex）的参数会用花括号 {} 界定。这大大提高了可读性。
- 返回值 ：不再打印通常不准确的函数返回值。
- 注意事项 ：如果一个参数只存在于寄存器中，并且在生成栈跟踪时没有被存储到内存（spilled to memory），那么打印出的该参数的值可能 不准确 。
为何升级 ：提升 panic 和 runtime.Stack 输出信息的可读性，让开发者更容易理解程序崩溃或特定时间点的函数调用状态。

允许内联包含闭包的函数 (Inlining Closures)

背景：内联 (Inlining) 是一种编译器优化，它将函数调用替换为函数体的实际代码，以减少函数调用的开销。闭包 (Closure) 是指引用了其外部作用域变量的函数。
之前行为 ：通常，包含闭包的函数不会被编译器内联。
Go 1.17 行为 ：编译器现在可以内联包含闭包的函数了。
潜在影响 ：
- 性能：可能带来性能提升，因为减少了函数调用开销。
- 代码指针 ：一个副作用是，如果一个带闭包的函数在多个地方被内联，每次内联可能会产生一个 不同的闭包代码指针 。Go 语言本身不允许直接比较函数值。但如果代码使用 reflect 或 unsafe.Pointer 绕过这个限制来比较函数（这本身就是不推荐的做法），那么这种行为可能会暴露这类代码中的潜在 bug，因为之前认为相同的函数现在可能因为内联而具有不同的代码指针。
为何升级 ：扩展编译器的优化能力，让更多函数（包括带闭包的）能够受益于内联优化，从而提升程序性能。

Go 1.17 编译器在 amd64 平台上的核心变化是引入了基于寄存器的调用约定，显著提升了性能。同时，改进了栈跟踪的可读性，并扩大了内联优化的范围。这些改动对大多数开发者是透明的，但使用 unsafe 或依赖底层细节（如函数指针比较）的代码需要注意可能的变化。

Go 1.17 相比 Go 1.16 有哪些值得注意的改动？