Go 1.22 相比 Go 1.21 有哪些值得注意的改動(dòng)？

作者：Pipeliu 2025-05-06 00:00:08

在 Go 1.22 之前，for?循環(huán)聲明的變量（例如?for i, v := range slice?中的?i?和?v）只會(huì)被創(chuàng)建一次。在每次迭代中，這些變量的值會(huì)被更新。這常常導(dǎo)致一個(gè)經(jīng)典的 bug：如果在循環(huán)內(nèi)部啟動(dòng)的 goroutine 引用了這些循環(huán)變量，它們可能會(huì)意外地共享同一個(gè)變量的最終值，而不是捕獲每次迭代時(shí)的值。

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

Go 1.22 值得關(guān)注的改動(dòng)：

for 循環(huán)改進(jìn) ：循環(huán)變量在每次迭代時(shí)創(chuàng)建新實(shí)例，避免閉包共享問(wèn)題；for range 現(xiàn)在支持遍歷整數(shù)。
工作區(qū)（Workspace）改進(jìn) ： go work 支持 vendor 目錄，允許工作區(qū)統(tǒng)一管理依賴(lài)。
vet 工具增強(qiáng) ：新增對(duì) defer 語(yǔ)句中 time.Since 錯(cuò)誤用法的警告。
運(yùn)行時(shí)（Runtime）優(yōu)化：通過(guò)改進(jìn)垃圾回收（Garbage Collection）元數(shù)據(jù)的存儲(chǔ)方式，提升了程序性能和內(nèi)存效率。
編譯器（Compiler）優(yōu)化：改進(jìn)了基于配置文件優(yōu)化（Profile-guided Optimization, PGO）的效果，并增強(qiáng)了內(nèi)聯(lián)（inlining）策略。
新增 math/rand/v2 包：引入了新的 math/rand/v2 包，提供了更現(xiàn)代、更快速的偽隨機(jī)數(shù)生成器和更符合 Go 習(xí)慣的 API。
新增 go/version 包：提供了用于驗(yàn)證和比較 Go 版本字符串的功能。
增強(qiáng)的 net/http 路由：標(biāo)準(zhǔn)庫(kù) net/http.ServeMux 支持更強(qiáng)大的路由模式，包括 HTTP 方法匹配和路徑參數(shù)（wildcards）。

下面是一些值得展開(kāi)的討論：

for 循環(huán)的兩項(xiàng)重要改進(jìn)

Go 1.22 對(duì) for 循環(huán)進(jìn)行了兩項(xiàng)重要的改進(jìn)：循環(huán)變量的語(yǔ)義變更和對(duì)整數(shù)的 range 支持。

1. 循環(huán)變量作用域變更

在 Go 1.22 之前，for 循環(huán)聲明的變量（例如 for i, v := range slice 中的 i 和 v）只會(huì)被創(chuàng)建一次。在每次迭代中，這些變量的值會(huì)被更新。這常常導(dǎo)致一個(gè)經(jīng)典的 bug：如果在循環(huán)內(nèi)部啟動(dòng)的 goroutine 引用了這些循環(huán)變量，它們可能會(huì)意外地共享同一個(gè)變量的最終值，而不是捕獲每次迭代時(shí)的值。

考慮以下 Go 1.21 及之前的代碼：

package main

import (
    "fmt"
    "time"
)

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

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

    time.Sleep(1 * time.Second) // 等待 goroutine 執(zhí)行
}

在 Go 1.21 及更早版本中，這段代碼很可能輸出三次 c，因?yàn)樗?goroutine 都捕獲了同一個(gè)變量 v，而當(dāng) goroutine 實(shí)際執(zhí)行時(shí)，循環(huán)已經(jīng)結(jié)束，v 的值停留在了最后一次迭代的 "c"。

為了解決這個(gè)問(wèn)題，開(kāi)發(fā)者通常需要顯式地在循環(huán)內(nèi)部創(chuàng)建一個(gè)新變量來(lái)捕獲當(dāng)前迭代的值：

// Go 1.21 及之前的修復(fù)方法
for _, v := range s {
    v := v // 創(chuàng)建一個(gè)新的 v，遮蔽（shadow）外層的 v
    go func() {
        fmt.Println(v)
    }()
}

從 Go 1.22 開(kāi)始，語(yǔ)言規(guī)范進(jìn)行了修改：每次循環(huán)迭代都會(huì)創(chuàng)建新的循環(huán)變量。這意味著，在 Go 1.22 中，無(wú)需任何修改，上面第一個(gè)例子就能按預(yù)期工作，輸出 a, b, c （順序不定，因?yàn)?goroutine 并發(fā)執(zhí)行）。這個(gè)改動(dòng)大大降低了因循環(huán)變量共享而出錯(cuò)的可能性。

2. for range 支持整數(shù)

Go 1.22 引入了一個(gè)便捷的語(yǔ)法糖：for range 現(xiàn)在可以直接用于整數(shù)類(lèi)型。for i := range n 的形式等價(jià)于 for i := 0; i < n; i++。這使得編寫(xiě)簡(jiǎn)單的計(jì)數(shù)循環(huán)更加簡(jiǎn)潔。

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

package main

import"fmt"

func main() {
    // Go 1.22 新增語(yǔ)法
    for i := range10 {
        fmt.Println(10 - i)
    }

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

    // 等價(jià)的 Go 1.21 及之前的寫(xiě)法
    // for i := 0; i < 10; i++ {
    //  fmt.Println(10 - i)
    // }
}

這個(gè)新特性簡(jiǎn)化了代碼，提高了可讀性。

此外，Go 1.22 還包含了一個(gè)實(shí)驗(yàn)性的語(yǔ)言特性預(yù)覽：支持對(duì)函數(shù)進(jìn)行 range 迭代（range-over-function iterators）。可以通過(guò)設(shè)置環(huán)境變量 GOEXPERIMENT=rangefunc 來(lái)啟用這個(gè)特性，但這仍處于試驗(yàn)階段，可能在未來(lái)的版本中發(fā)生變化。

工作區(qū)（Workspaces）支持 vendor 目錄

Go 1.22 增強(qiáng)了對(duì)工作區(qū)（Workspaces）模式的支持，引入了對(duì) vendor 目錄的集成。

在 Go 1.21 及之前，vendor 目錄是模塊（module）級(jí)別的特性。每個(gè)模塊可以有自己的 vendor 目錄，存放該模塊的依賴(lài)項(xiàng)。然而，在使用 Go 工作區(qū)管理多個(gè)相互關(guān)聯(lián)的模塊時(shí)，并沒(méi)有統(tǒng)一的 vendor 機(jī)制。開(kāi)發(fā)者可能需要在每個(gè)模塊下單獨(dú)執(zhí)行 go mod vendor，或者依賴(lài) Go 工具鏈自動(dòng)查找各個(gè)模塊的依賴(lài)。

Go 1.22 引入了 go work vendor 命令。當(dāng)你在工作區(qū)的根目錄下運(yùn)行此命令時(shí)，它會(huì)創(chuàng)建一個(gè)頂級(jí)的 vendor 目錄，并將工作區(qū)內(nèi)所有模塊的全部依賴(lài)項(xiàng) 收集到這個(gè)目錄中。

之后，當(dāng)你在工作區(qū)內(nèi)執(zhí)行構(gòu)建命令（如 go build, go test）時(shí)，如果存在這個(gè)頂級(jí)的 vendor 目錄，Go 工具鏈默認(rèn)會(huì)使用 -mod=vendor 標(biāo)志，優(yōu)先從這個(gè) vendor 目錄中查找依賴(lài)，而不是去下載或者查找本地 GOPATH 或模塊緩存。

這帶來(lái)了幾個(gè)好處：

依賴(lài)隔離與一致性：確保整個(gè)工作區(qū)內(nèi)的所有模塊都使用同一套經(jīng)過(guò) vendor 固定的依賴(lài)版本，增強(qiáng)了構(gòu)建的確定性和可復(fù)現(xiàn)性。
簡(jiǎn)化離線構(gòu)建：只需要一個(gè)頂級(jí)的 vendor 目錄，就可以支持整個(gè)工作區(qū)的離線構(gòu)建。
統(tǒng)一管理：無(wú)需在每個(gè)子模塊中維護(hù)各自的 vendor 目錄。

需要注意的是，工作區(qū)的 vendor 目錄與單個(gè)模塊的 vendor 目錄是不同的。如果工作區(qū)的根目錄恰好也是其中一個(gè)模塊的根目錄，那么該目錄下的 vendor 子目錄要么服務(wù)于整個(gè)工作區(qū)（由 go work vendor 創(chuàng)建），要么服務(wù)于該模塊本身（由 go mod vendor 創(chuàng)建），但不能同時(shí)服務(wù)兩者。

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

在舊的 GOPATH 模式下（即設(shè)置 GO111MODULE=off），go get 命令不再被支持。但其他構(gòu)建命令如 go build 和 go test 仍將無(wú)限期支持 GOPATH 項(xiàng)目。
go mod init 不再?lài)L試從其他包管理工具（如 Gopkg.lock）的配置文件中導(dǎo)入依賴(lài)。
go test -cover 現(xiàn)在會(huì)為那些沒(méi)有自己測(cè)試文件但被覆蓋到的包輸出覆蓋率摘要（通常是 0.0%），而不是之前的 [no test files] 提示。
如果構(gòu)建命令需要調(diào)用外部 C 鏈接器（external linker），但 cgo 未啟用，現(xiàn)在會(huì)報(bào)錯(cuò)。因?yàn)?Go 運(yùn)行時(shí)需要 cgo 支持來(lái)確保與 C 鏈接器添加的庫(kù)兼容。

vet 工具對(duì) defer time.Since 的新警告

Go 1.22 中的 vet 工具增加了一項(xiàng)檢查，用于識(shí)別 defer 語(yǔ)句中對(duì) time.Since 的常見(jiàn)誤用。

考慮以下代碼片段，其目的是在函數(shù)退出時(shí)記錄執(zhí)行耗時(shí)：

package main

import (
    "log"
    "time"
)

func operation() {
    t := time.Now()
    // 常見(jiàn)的錯(cuò)誤用法：
    defer log.Println(time.Since(t)) // vet 在 Go 1.22 中會(huì)對(duì)此發(fā)出警告

    // 模擬一些耗時(shí)操作
    time.Sleep(100 * time.Millisecond)
}

func main() {
    operation()
}

許多開(kāi)發(fā)者期望 defer log.Println(time.Since(t)) 會(huì)在 operation 函數(shù)即將返回時(shí)計(jì)算 time.Since(t)，從而得到 operation 函數(shù)的精確執(zhí)行時(shí)間。然而，defer 的工作機(jī)制并非如此。

defer 語(yǔ)句會(huì)將其后的函數(shù)調(diào)用推遲到包含 defer 的函數(shù)即將返回之前執(zhí)行。但是，函數(shù)調(diào)用的參數(shù)是在 defer 語(yǔ)句執(zhí)行時(shí)就被立即計(jì)算（evaluated）并保存的。

因此，在 defer log.Println(time.Since(t)) 這行代碼執(zhí)行時(shí)：

time.Since(t) 被立即調(diào)用。由于 t 剛剛被設(shè)置為 time.Now()，此時(shí) time.Since(t) 的結(jié)果幾乎為 0（或一個(gè)非常小的值）。
log.Println 函數(shù)及其（幾乎為 0 的）參數(shù)被注冊(cè)為一個(gè)延遲調(diào)用。
當(dāng) operation 函數(shù)結(jié)束時(shí)，被推遲的 log.Println 函數(shù)被執(zhí)行，打印出那個(gè)在 defer 語(yǔ)句執(zhí)行時(shí)就已經(jīng)計(jì)算好的、非常小的時(shí)間差。

這顯然不是我們想要的。vet 工具現(xiàn)在會(huì)警告這種模式，因?yàn)樗鼛缀蹩偸清e(cuò)誤的。

正確的做法是確保 time.Since(t) 在延遲函數(shù) 實(shí)際執(zhí)行時(shí) 才被調(diào)用。這通常通過(guò)一個(gè)閉包（匿名函數(shù)）來(lái)實(shí)現(xiàn)：

package main

import (
    "log"
    "time"
)

func operationCorrect() {
    t := time.Now()
    // 正確用法：
    deferfunc() {
        // time.Since(t) 在 defer 的函數(shù)體內(nèi)部被調(diào)用
        // 這確保了它在 operationCorrect 即將返回時(shí)才計(jì)算時(shí)間差
        log.Println(time.Since(t))
    }()

    // 模擬一些耗時(shí)操作
    time.Sleep(100 * time.Millisecond)
}

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

在這個(gè)正確的版本中，defer 后面跟著的是一個(gè)匿名函數(shù) func() { ... }。這個(gè)匿名函數(shù)本身被推遲執(zhí)行。當(dāng) operationCorrect 即將返回時(shí)，這個(gè)匿名函數(shù)被調(diào)用，此時(shí)它內(nèi)部的 time.Since(t) 才會(huì)被執(zhí)行，從而正確計(jì)算出從 t 被賦值到函數(shù)返回的總時(shí)長(zhǎng)。

vet 的這項(xiàng)新檢查有助于開(kāi)發(fā)者避免這個(gè)常見(jiàn)的 defer 陷阱，確保計(jì)時(shí)邏輯的正確性。

運(yùn)行時(shí)優(yōu)化：改進(jìn) GC 元數(shù)據(jù)布局

Go 1.22 運(yùn)行時(shí)進(jìn)行了一項(xiàng)優(yōu)化，改變了垃圾回收（Garbage Collection, GC）所需的類(lèi)型元數(shù)據(jù)（type-based metadata）的存儲(chǔ)方式。現(xiàn)在，這些元數(shù)據(jù)被存儲(chǔ)得更靠近堆（heap）上的對(duì)象本身。

這項(xiàng)改變帶來(lái)了兩個(gè)主要好處：

性能提升：通過(guò)讓 GC 元數(shù)據(jù)與對(duì)象在內(nèi)存中物理位置更近，利用了 CPU 緩存的局部性原理（locality of reference）。當(dāng) GC 需要訪問(wèn)對(duì)象的元數(shù)據(jù)時(shí)，這些數(shù)據(jù)更有可能已經(jīng)在 CPU 緩存中，減少了從主內(nèi)存讀取數(shù)據(jù)的延遲。這使得 Go 程序的 CPU 性能（延遲或吞吐量）提升了 1-3%。
內(nèi)存開(kāi)銷(xiāo)降低：通過(guò)重新組織元數(shù)據(jù)，運(yùn)行時(shí)能夠更好地去重（deduplicate）冗余的元數(shù)據(jù)信息。對(duì)于大多數(shù) Go 程序，這可以減少約 1% 的內(nèi)存開(kāi)銷(xiāo)。

為了理解這個(gè)變化，我們可以做一個(gè)簡(jiǎn)單的類(lèi)比（注意這只是一個(gè)幫助理解的概念模型，并非內(nèi)存布局的精確表示）：

假設(shè)在 Go 1.21 中，堆內(nèi)存布局可能像這樣：

[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 需要在對(duì)象頭和可能相距較遠(yuǎn)的元數(shù)據(jù)區(qū)之間跳轉(zhuǎn)。

在 Go 1.22 中，布局可能更接近這樣：

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

元數(shù)據(jù)緊鄰對(duì)象頭，提高了訪問(wèn)效率。同時(shí)，如果多個(gè)對(duì)象共享相同的元數(shù)據(jù)，運(yùn)行時(shí)可以更有效地管理這些共享信息，減少總體內(nèi)存占用。

然而，這項(xiàng)優(yōu)化也帶來(lái)了一個(gè)潛在的副作用：內(nèi)存對(duì)齊（memory alignment）的變化。

在此更改之前，Go 的內(nèi)存分配器（memory allocator）傾向于將對(duì)象分配在 16 字節(jié)（或更高）對(duì)齊的內(nèi)存地址上。但優(yōu)化后的元數(shù)據(jù)布局調(diào)整了內(nèi)存分配器的內(nèi)部大小類(lèi)別（size class）邊界。因此，某些對(duì)象現(xiàn)在可能只保證 8 字節(jié)對(duì)齊，而不是之前的 16 字節(jié)。

對(duì)于絕大多數(shù)純 Go 代碼來(lái)說(shuō)，這個(gè)變化沒(méi)有影響。但是，如果你的代碼中包含手寫(xiě)的匯編（assembly）代碼，并且這些匯編代碼依賴(lài)于 Go 對(duì)象地址具有超過(guò) 8 字節(jié)的對(duì)齊保證（例如，使用了需要 16 字節(jié)對(duì)齊地址的 SIMD 指令），那么這些代碼在 Go 1.22 下可能會(huì)失效。

Go 團(tuán)隊(duì)預(yù)計(jì)這種情況非常罕見(jiàn)。但如果確實(shí)遇到了問(wèn)題，可以臨時(shí)使用 GOEXPERIMENT=noallocheaders 構(gòu)建程序來(lái)恢復(fù)舊的元數(shù)據(jù)布局和對(duì)齊行為。不過(guò)，這只是一個(gè)臨時(shí)的解決方案，包的維護(hù)者應(yīng)該盡快更新他們的匯編代碼，移除對(duì)特定內(nèi)存對(duì)齊的假設(shè)，因?yàn)檫@個(gè) GOEXPERIMENT 標(biāo)志將在未來(lái)的版本中被移除。

編譯器優(yōu)化：更強(qiáng)的 PGO 和內(nèi)聯(lián)

Go 1.22 編譯器在優(yōu)化方面取得了進(jìn)展，特別是增強(qiáng)了基于配置文件優(yōu)化（Profile-guided Optimization, PGO）和內(nèi)聯(lián)（inlining）策略。

1. PGO 效果增強(qiáng)

PGO 是一種編譯器優(yōu)化技術(shù)，它利用程序運(yùn)行時(shí)的真實(shí)執(zhí)行數(shù)據(jù)（profile）來(lái)指導(dǎo)編譯過(guò)程，做出更優(yōu)的決策。在 Go 1.22 中，PGO 的一個(gè)關(guān)鍵改進(jìn)是能夠去虛擬化（devirtualization）更高比例的接口方法調(diào)用。

去虛擬化是指編譯器能夠確定一個(gè)接口變量在某個(gè)調(diào)用點(diǎn)實(shí)際指向的具體類(lèi)型，從而將原本需要通過(guò)接口查找（動(dòng)態(tài)分派）的方法調(diào)用替換為對(duì)具體類(lèi)型方法的直接調(diào)用（靜態(tài)分派）。直接調(diào)用通常比接口調(diào)用更快。

想象一下這樣的代碼：

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

func writeData(w Writer, data []byte) {
    w.Write(data) // 這是一個(gè)接口調(diào)用
}

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

func main() {
    // ...
    f := &fileWriter{}
    // 假設(shè) PGO 數(shù)據(jù)顯示 writeData 總是或經(jīng)常被 fileWriter 調(diào)用
    writeData(f, someData)
}

如果 PGO 數(shù)據(jù)表明 writeData 函數(shù)中的 w 變量在運(yùn)行時(shí)絕大多數(shù)情況下都是 *fileWriter 類(lèi)型，Go 1.22 的編譯器就更有可能將 w.Write(data) 這個(gè)接口調(diào)用優(yōu)化為對(duì) f.Write(data) 的直接調(diào)用，從而提升性能。

得益于這種更強(qiáng)的去虛擬化能力以及其他 PGO 改進(jìn)，現(xiàn)在大多數(shù) Go 程序在啟用 PGO 后，可以觀察到 2% 到 14% 的運(yùn)行時(shí)性能提升。

2. 改進(jìn)的內(nèi)聯(lián)策略

內(nèi)聯(lián)是將函數(shù)調(diào)用替換為函數(shù)體本身的操作，可以消除函數(shù)調(diào)用的開(kāi)銷(xiāo)，并為其他優(yōu)化（如常量傳播、死代碼消除）創(chuàng)造機(jī)會(huì)。

Go 1.22 編譯器現(xiàn)在能夠更好地交織（interleave）去虛擬化和內(nèi)聯(lián) 。這意味著，即使是接口方法調(diào)用，在經(jīng)過(guò) PGO 去虛擬化變成直接調(diào)用后，也可能更容易被內(nèi)聯(lián)，進(jìn)一步優(yōu)化性能。

此外，Go 1.22 還包含了一個(gè) 實(shí)驗(yàn)性的增強(qiáng)內(nèi)聯(lián)器。這個(gè)新的內(nèi)聯(lián)器使用啟發(fā)式規(guī)則（heuristics）來(lái)更智能地決定是否內(nèi)聯(lián)。它會(huì)傾向于在被認(rèn)為是“重要”的調(diào)用點(diǎn)（例如循環(huán)內(nèi)部）進(jìn)行內(nèi)聯(lián)，而在被認(rèn)為是“不重要”的調(diào)用點(diǎn)（例如 panic 路徑上）則減少內(nèi)聯(lián)，以平衡性能提升和代碼體積的增長(zhǎng)。

可以通過(guò)設(shè)置環(huán)境變量 GOEXPERIMENT=newinliner 來(lái)啟用這個(gè)新的實(shí)驗(yàn)性?xún)?nèi)聯(lián)器。相關(guān)的討論和反饋可以在 https://github.com/golang/go/issues/61502 中找到。

增強(qiáng)的 net/http 路由模式

Go 1.22 對(duì)標(biāo)準(zhǔn)庫(kù)中的 net/http.ServeMux 進(jìn)行了顯著增強(qiáng)，使其路由模式（patterns）更具表現(xiàn)力，引入了對(duì) HTTP 方法和路徑參數(shù)（wildcards）的支持。

在此之前，http.ServeMux 的路由功能非常基礎(chǔ)，基本上只能基于 URL 路徑前綴進(jìn)行匹配。這使得實(shí)現(xiàn) RESTful API 或更復(fù)雜的路由邏輯時(shí)，開(kāi)發(fā)者往往需要引入第三方的路由庫(kù)。

Go 1.22 的改進(jìn)使得標(biāo)準(zhǔn)庫(kù)的路由能力大大增強(qiáng)：

1. HTTP 方法匹配

現(xiàn)在可以在注冊(cè)處理器（handler）時(shí)指定 HTTP 方法。

package main

import (
    "fmt"
    "net/http"
)

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

    // 只匹配 POST 請(qǐng)求到 /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 只會(huì)匹配 POST 方法的請(qǐng)求。
帶有方法的模式優(yōu)先級(jí)高于不帶方法的通用模式。例如，一個(gè) POST 請(qǐng)求到 /items/create 會(huì)被第一個(gè)處理器處理，而一個(gè) GET 請(qǐng)求到 /items/create 則會(huì)回退（fall back）到匹配 /items/ 的處理器（如果存在且匹配的話）。
特殊情況：注冊(cè) GET 方法的處理器會(huì)自動(dòng)也為 HEAD 請(qǐng)求注冊(cè)相同的處理器。

2. 路徑參數(shù)（Wildcards）

模式中可以使用 {} 來(lái)定義路徑參數(shù)（也叫路徑變量或通配符）。

package main

import (
    "fmt"
    "net/http"
)

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

    // 匹配如 /items/123, /items/abc 等
    // {id} 匹配路徑中的一個(gè)段 (segment)
    mux.HandleFunc("/items/{id}", func(w http.ResponseWriter, r *http.Request) {
        // 通過(guò) r.PathValue("id") 獲取實(shí)際匹配到的值
        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 路徑中的單個(gè)段。
{name...} 形式的通配符必須出現(xiàn)在模式的末尾，它會(huì)匹配該點(diǎn)之后的所有剩余路徑段。
可以使用 r.PathValue("name") 在處理器函數(shù)中獲取通配符匹配到的實(shí)際值。

3. 精確匹配與后綴斜杠

像以前一樣，以 / 結(jié)尾的模式（如 /static/）會(huì)匹配所有以此為前綴的路徑。
如果想要精確匹配一個(gè)以斜杠結(jié)尾的路徑（而不是作為前綴匹配），可以在末尾加上 {$}，例如 /exact/match/{$} 只會(huì)匹配 /exact/match/ 而不會(huì)匹配 /exact/match/foo。

4. 優(yōu)先級(jí)規(guī)則

當(dāng)兩個(gè)模式可能匹配同一個(gè)請(qǐng)求時(shí)（模式重疊），更具體（more specific）的模式優(yōu)先。如果兩者沒(méi)有明確的哪個(gè)更具體，則模式?jīng)_突（注冊(cè)時(shí)會(huì) panic）。這個(gè)規(guī)則推廣了之前的優(yōu)先級(jí)規(guī)則，并保證了注冊(cè)順序不影響最終的匹配結(jié)果。例如：

POST /items/{id} 比 /items/{id} 更具體（因?yàn)樗付朔椒ǎ?/li>
/items/specific 比 /items/{id} 更具體（因?yàn)樗艘粋€(gè)字面量段而不是通配符）。
/a/{x}/b 和 /a/{y}/c 沒(méi)有明確的哪個(gè)更具體，如果它們可能匹配相同的請(qǐng)求路徑（例如 /a/foo/b 和 /a/foo/c 不沖突，但 /a/{z} 和 /a/b 可能會(huì)沖突），這取決于具體實(shí)現(xiàn)，但通常 /a/b 會(huì)優(yōu)先于 /a/{z}。