Go 1.22 相比 Go 1.21 有哪些值得注意的改动？

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

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

Go 1.22 值得关注的改动：

1. for 循环改进 ： 循环变量在每次迭代时创建新实例，避免闭包共享问题；for range 现在支持遍历整数。
2. 工作区（Workspace）改进 ： go work 支持 vendor 目录，允许工作区统一管理依赖。
3. vet 工具增强 ： 新增对 defer 语句中 time.Since 错误用法的警告。
4. 运行时（Runtime）优化 ： 通过改进垃圾回收（Garbage Collection）元数据的存储方式，提升了程序性能和内存效率。
5. 编译器（Compiler）优化 ： 改进了基于配置文件优化（Profile-guided Optimization, PGO）的效果，并增强了内联（inlining）策略。
6. 新增 math/rand/v2 包 ： 引入了新的 math/rand/v2 包，提供了更现代、更快速的伪随机数生成器和更符合 Go 习惯的 API。
7. 新增 go/version 包 ： 提供了用于验证和比较 Go 版本字符串的功能。
8. 增强的 net/http 路由 ： 标准库 net/http.ServeMux 支持更强大的路由模式，包括 HTTP 方法匹配和路径参数（wildcards）。

下面是一些值得展开的讨论：

for 循环的两项重要改进

Go 1.22 对 for 循环进行了两项重要的改进：循环变量的语义变更和对整数的 range 支持。

1. 循环变量作用域变更

在 Go 1.22 之前，for 循环声明的变量（例如 for i, v := range slice 中的 i 和 v）只会被创建一次。在每次迭代中，这些变量的值会被更新。这常常导致一个经典的 bug：如果在循环内部启动的 goroutine 引用了这些循环变量，它们可能会意外地共享同一个变量的最终值，而不是捕获每次迭代时的值。

考虑以下 Go 1.21 及之前的代码：

package main

import (
    "fmt"
    "time"
)

func main() {
    s := []string{"a", "b", "c"}

    for _, v := range s {
        go func() {
            fmt.Println(v) // 期望输出 a, b, c
        }()
    }

    time.Sleep(1 * time.Second) // 等待 goroutine 执行
}

在 Go 1.21 及更早版本中，这段代码很可能输出三次 c，因为所有 goroutine 都捕获了同一个变量 v，而当 goroutine 实际执行时，循环已经结束，v 的值停留在了最后一次迭代的 "c"。

为了解决这个问题，开发者通常需要显式地在循环内部创建一个新变量来捕获当前迭代的值：

// Go 1.21 及之前的修复方法
for _, v := range s {
    v := v // 创建一个新的 v，遮蔽（shadow）外层的 v
    go func() {
        fmt.Println(v)
    }()
}

从 Go 1.22 开始，语言规范进行了修改： 每次循环迭代都会创建新的循环变量 。这意味着，在 Go 1.22 中，无需任何修改，上面第一个例子就能按预期工作，输出 a, b, c （顺序不定，因为 goroutine 并发执行）。这个改动大大降低了因循环变量共享而出错的可能性。

2. for range 支持整数

Go 1.22 引入了一个便捷的语法糖：for range 现在可以直接用于整数类型。for i := range n 的形式等价于 for i := 0; i < n; i++。这使得编写简单的计数循环更加简洁。

例如，要倒序打印 10 到 1：

package main

import "fmt"

func main() {
    // Go 1.22 新增语法
    for i := range 10 {
        fmt.Println(10 - i)
    }

    fmt.Println("go1.22 has lift-off!")

    // 等价的 Go 1.21 及之前的写法
    // for i := 0; i < 10; i++ {
    //  fmt.Println(10 - i)
    // }
}

这个新特性简化了代码，提高了可读性。

此外，Go 1.22 还包含了一个实验性的语言特性预览：支持对函数进行 range 迭代（range-over-function iterators）。可以通过设置环境变量 GOEXPERIMENT=rangefunc 来启用这个特性，但这仍处于试验阶段，可能在未来的版本中发生变化。

工作区（Workspaces）支持 vendor 目录

Go 1.22 增强了对工作区（Workspaces）模式的支持，引入了对 vendor 目录的集成。

在 Go 1.21 及之前，vendor 目录是模块（module）级别的特性。每个模块可以有自己的 vendor 目录，存放该模块的依赖项。然而，在使用 Go 工作区管理多个相互关联的模块时，并没有统一的 vendor 机制。开发者可能需要在每个模块下单独执行 go mod vendor，或者依赖 Go 工具链自动查找各个模块的依赖。

Go 1.22 引入了 go work vendor 命令。当你在工作区的根目录下运行此命令时，它会创建一个顶级的 vendor 目录，并将工作区内所有模块的 全部依赖项 收集到这个目录中。

之后，当你在工作区内执行构建命令（如 go build, go test）时，如果存在这个顶级的 vendor 目录，Go 工具链默认会使用 -mod=vendor 标志，优先从这个 vendor 目录中查找依赖，而不是去下载或者查找本地 GOPATH 或模块缓存。

这带来了几个好处：

1. 依赖隔离与一致性 ： 确保整个工作区内的所有模块都使用同一套经过 vendor 固定的依赖版本，增强了构建的确定性和可复现性。
2. 简化离线构建 ： 只需要一个顶级的 vendor 目录，就可以支持整个工作区的离线构建。
3. 统一管理 ： 无需在每个子模块中维护各自的 vendor 目录。

需要注意的是，工作区的 vendor 目录与单个模块的 vendor 目录是不同的。如果工作区的根目录恰好也是其中一个模块的根目录，那么该目录下的 vendor 子目录要么服务于整个工作区（由 go work vendor 创建），要么服务于该模块本身（由 go mod vendor 创建），但不能同时服务两者。

此外，Go 1.22 的 go 命令还有一些其他变化：

• 在旧的 GOPATH 模式下（即设置 GO111MODULE=off），go get 命令不再被支持。但其他构建命令如 go build 和 go test 仍将无限期支持 GOPATH 项目。
• go mod init 不再尝试从其他包管理工具（如 Gopkg.lock）的配置文件中导入依赖。
• go test -cover 现在会为那些没有自己测试文件但被覆盖到的包输出覆盖率摘要（通常是 0.0%），而不是之前的 [no test files] 提示。
• 如果构建命令需要调用外部 C 链接器（external linker），但 cgo 未启用，现在会报错。因为 Go 运行时需要 cgo 支持来确保与 C 链接器添加的库兼容。

vet 工具对 defer time.Since 的新警告

Go 1.22 中的 vet 工具增加了一项检查，用于识别 defer 语句中对 time.Since 的常见误用。

考虑以下代码片段，其目的是在函数退出时记录执行耗时：

package main

import (
    "log"
    "time"
)

func operation() {
    t := time.Now()
    // 常见的错误用法：
    defer log.Println(time.Since(t)) // vet 在 Go 1.22 中会对此发出警告

    // 模拟一些耗时操作
    time.Sleep(100 * time.Millisecond)
}

func main() {
    operation()
}

许多开发者期望 defer log.Println(time.Since(t)) 会在 operation 函数即将返回时计算 time.Since(t)，从而得到 operation 函数的精确执行时间。然而，defer 的工作机制并非如此。

defer 语句会将其后的 函数调用 推迟到包含 defer 的函数即将返回之前执行。但是， 函数调用的参数是在 defer 语句执行时就被立即计算（evaluated）并保存的 。

因此，在 defer log.Println(time.Since(t)) 这行代码执行时：

1. time.Since(t) 被 立即调用 。由于 t 刚刚被设置为 time.Now()，此时 time.Since(t) 的结果几乎为 0（或一个非常小的值）。
2. log.Println 函数及其（几乎为 0 的）参数被注册为一个延迟调用。
3. 当 operation 函数结束时，被推迟的 log.Println 函数被执行，打印出那个在 defer 语句执行时就已经计算好的、非常小的时间差。

这显然不是我们想要的。vet 工具现在会警告这种模式，因为它几乎总是错误的。

正确的做法是确保 time.Since(t) 在延迟函数 实际执行时 才被调用。这通常通过一个闭包（匿名函数）来实现：

package main

import (
    "log"
    "time"
)

func operationCorrect() {
    t := time.Now()
    // 正确用法：
    defer func() {
        // time.Since(t) 在 defer 的函数体内部被调用
        // 这确保了它在 operationCorrect 即将返回时才计算时间差
        log.Println(time.Since(t))
    }()

    // 模拟一些耗时操作
    time.Sleep(100 * time.Millisecond)
}

func main() {
    operationCorrect() // 输出接近 100ms 的值
}

在这个正确的版本中，defer 后面跟着的是一个匿名函数 func() { ... }。这个匿名函数本身被推迟执行。当 operationCorrect 即将返回时，这个匿名函数被调用，此时它内部的 time.Since(t) 才会被执行，从而正确计算出从 t 被赋值到函数返回的总时长。

vet 的这项新检查有助于开发者避免这个常见的 defer 陷阱，确保计时逻辑的正确性。

运行时优化：改进 GC 元数据布局

Go 1.22 运行时进行了一项优化，改变了垃圾回收（Garbage Collection, GC）所需的类型元数据（type-based metadata）的存储方式。现在，这些元数据被存储得更靠近堆（heap）上的对象本身。

这项改变带来了两个主要好处：

1. 性能提升 ： 通过让 GC 元数据与对象在内存中物理位置更近，利用了 CPU 缓存的局部性原理（locality of reference）。当 GC 需要访问对象的元数据时，这些数据更有可能已经在 CPU 缓存中，减少了从主内存读取数据的延迟。这使得 Go 程序的 CPU 性能（延迟或吞吐量）提升了 1-3%。
2. 内存开销降低 ： 通过重新组织元数据，运行时能够更好地去重（deduplicate）冗余的元数据信息。对于大多数 Go 程序，这可以减少约 1% 的内存开销。

为了理解这个变化，我们可以做一个简单的类比（注意这只是一个帮助理解的概念模型，并非内存布局的精确表示）：

假设在 Go 1.21 中，堆内存布局可能像这样：

[Object A Header] [Object A Data...]   [Object B Header] [Object B Data...]
        |                                       |
        +-----------------+                     +-----------------+
                          |                                       |
                          V                                       V
                  [Metadata Area: Type Info for A, ...]   [Metadata Area: Type Info for B, ...]

GC 需要在对象头和可能相距较远的元数据区之间跳转。

在 Go 1.22 中，布局可能更接近这样：

[Object A Header | Metadata for A] [Object A Data...]   [Object B Header | Metadata for B] [Object B Data...]

元数据紧邻对象头，提高了访问效率。同时，如果多个对象共享相同的元数据，运行时可以更有效地管理这些共享信息，减少总体内存占用。

然而，这项优化也带来了一个潜在的副作用： 内存对齐（memory alignment）的变化 。

在此更改之前，Go 的内存分配器（memory allocator）倾向于将对象分配在 16 字节（或更高）对齐的内存地址上。但优化后的元数据布局调整了内存分配器的内部大小类别（size class）边界。因此，某些对象现在可能只保证 8 字节对齐，而不是之前的 16 字节。

对于绝大多数纯 Go 代码来说，这个变化没有影响。但是，如果你的代码中包含手写的汇编（assembly）代码，并且这些汇编代码依赖于 Go 对象地址具有超过 8 字节的对齐保证（例如，使用了需要 16 字节对齐地址的 SIMD 指令），那么这些代码在 Go 1.22 下可能会失效。

Go 团队预计这种情况非常罕见。但如果确实遇到了问题，可以临时使用 GOEXPERIMENT=noallocheaders 构建程序来恢复旧的元数据布局和对齐行为。不过，这只是一个临时的解决方案，包的维护者应该尽快更新他们的汇编代码，移除对特定内存对齐的假设，因为这个 GOEXPERIMENT 标志将在未来的版本中被移除。

编译器优化：更强的 PGO 和内联

Go 1.22 编译器在优化方面取得了进展，特别是增强了基于配置文件优化（Profile-guided Optimization, PGO）和内联（inlining）策略。

1. PGO 效果增强

PGO 是一种编译器优化技术，它利用程序运行时的真实执行数据（profile）来指导编译过程，做出更优的决策。在 Go 1.22 中，PGO 的一个关键改进是能够 去虚拟化（devirtualization） 更高比例的接口方法调用。

去虚拟化是指编译器能够确定一个接口变量在某个调用点实际指向的具体类型，从而将原本需要通过接口查找（动态分派）的方法调用替换为对具体类型方法的直接调用（静态分派）。直接调用通常比接口调用更快。

想象一下这样的代码：

type Writer interface {
    Write([]byte) (int, error)
}

func writeData(w Writer, data []byte) {
    w.Write(data) // 这是一个接口调用
}

type fileWriter struct { /* ... */ }
func (fw *fileWriter) Write(p []byte) (int, error) { /* ... */ }

func main() {
    // ...
    f := &fileWriter{}
    // 假设 PGO 数据显示 writeData 总是或经常被 fileWriter 调用
    writeData(f, someData)
}

如果 PGO 数据表明 writeData 函数中的 w 变量在运行时绝大多数情况下都是 *fileWriter 类型，Go 1.22 的编译器就更有可能将 w.Write(data) 这个接口调用优化为对 f.Write(data) 的直接调用，从而提升性能。

得益于这种更强的去虚拟化能力以及其他 PGO 改进，现在大多数 Go 程序在启用 PGO 后，可以观察到 2% 到 14% 的运行时性能提升。

2. 改进的内联策略

内联是将函数调用替换为函数体本身的操作，可以消除函数调用的开销，并为其他优化（如常量传播、死代码消除）创造机会。

Go 1.22 编译器现在能够更好地 交织（interleave）去虚拟化和内联 。这意味着，即使是接口方法调用，在经过 PGO 去虚拟化变成直接调用后，也可能更容易被内联，进一步优化性能。

此外，Go 1.22 还包含了一个 实验性的增强内联器 。这个新的内联器使用启发式规则（heuristics）来更智能地决定是否内联。它会倾向于在被认为是"重要"的调用点（例如循环内部）进行内联，而在被认为是"不重要"的调用点（例如 panic 路径上）则减少内联，以平衡性能提升和代码体积的增长。

可以通过设置环境变量 GOEXPERIMENT=newinliner 来启用这个新的实验性内联器。相关的讨论和反馈可以在 https://github.com/golang/go/issues/61502 中找到。

增强的 net/http 路由模式

Go 1.22 对标准库中的 net/http.ServeMux 进行了显著增强，使其路由模式（patterns）更具表现力，引入了对 HTTP 方法和路径参数（wildcards）的支持。

在此之前，http.ServeMux 的路由功能非常基础，基本上只能基于 URL 路径前缀进行匹配。这使得实现 RESTful API 或更复杂的路由逻辑时，开发者往往需要引入第三方的路由库。

Go 1.22 的改进使得标准库的路由能力大大增强：

1. HTTP 方法匹配

现在可以在注册处理器（handler）时指定 HTTP 方法。

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    // 只匹配 POST 请求到 /items/create
    mux.HandleFunc("POST /items/create", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "Create item")
    })

    // 匹配所有方法的 /items/
    mux.HandleFunc("/items/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Default item handler for method %s\n", r.Method)
    })

    // http.ListenAndServe(":8080", mux)
}

• POST /items/create 只会匹配 POST 方法的请求。
• 带有方法的模式优先级高于不带方法的通用模式。例如，一个 POST 请求到 /items/create 会被第一个处理器处理，而一个 GET 请求到 /items/create 则会回退（fall back）到匹配 /items/ 的处理器（如果存在且匹配的话）。
• 特殊情况：注册 GET 方法的处理器会自动也为 HEAD 请求注册相同的处理器。

2. 路径参数（Wildcards）

模式中可以使用 {} 来定义路径参数（也叫路径变量或通配符）。

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()

    // 匹配如 /items/123, /items/abc 等
    // {id} 匹配路径中的一个段 (segment)
    mux.HandleFunc("/items/{id}", func(w http.ResponseWriter, r *http.Request) {
        // 通过 r.PathValue("id") 获取实际匹配到的值
        itemID := r.PathValue("id")
        fmt.Fprintf(w, "Get item with ID: %s\n", itemID)
    })

    // 匹配如 /files/a/b/c.txt
    // {path...} 必须在末尾，匹配剩余所有路径段
    mux.HandleFunc("/files/{path...}", func(w http.ResponseWriter, r *http.Request) {
        filePath := r.PathValue("path")
        fmt.Fprintf(w, "Accessing file path: %s\n", filePath)
    })

    // http.ListenAndServe(":8080", mux)
}

• {name} 形式的通配符匹配 URL 路径中的单个段。
• {name...} 形式的通配符必须出现在模式的末尾，它会匹配该点之后的所有剩余路径段。
• 可以使用 r.PathValue("name") 在处理器函数中获取通配符匹配到的实际值。

3. 精确匹配与后缀斜杠

• 像以前一样，以 / 结尾的模式（如 /static/）会匹配所有以此为前缀的路径。
• 如果想要精确匹配一个以斜杠结尾的路径（而不是作为前缀匹配），可以在末尾加上 {$}，例如 /exact/match/{$} 只会匹配 /exact/match/ 而不会匹配 /exact/match/foo。

4. 优先级规则

当两个模式可能匹配同一个请求时（模式重叠），更具体（more specific） 的模式优先。如果两者没有明确的哪个更具体，则模式冲突（注册时会 panic）。这个规则推广了之前的优先级规则，并保证了注册顺序不影响最终的匹配结果。

例如：

• POST /items/{id} 比 /items/{id} 更具体（因为它指定了方法）。
• /items/specific 比 /items/{id} 更具体（因为它包含了一个字面量段而不是通配符）。
• /a/{x}/b 和 /a/{y}/c 没有明确的哪个更具体，如果它们可能匹配相同的请求路径（例如 /a/foo/b 和 /a/foo/c 不冲突，但 /a/{z} 和 /a/b 可能会冲突），这取决于具体实现，但通常 /a/b 会优先于 /a/{z}。

5. 向后兼容性

这些改动在某些方面破坏了向后兼容性：

• 包含 { 和 } 的路径现在会被解析为带通配符的模式，行为与之前不同。
• 对路径中转义字符的处理也得到了改进，可能导致行为差异。

为了帮助平滑过渡，可以通过设置 GODEBUG 环境变量来恢复旧的行为：

export GODEBUG=httpmuxgo121=1

总的来说，Go 1.22 对 net/http.ServeMux 的增强大大提升了标准库进行 Web 开发的能力，减少了对第三方路由库的依赖。