Go 1.18 Release Note 中文版

目錄

• Go 1.18簡(jiǎn)介

• 語(yǔ)言的變化

• 泛型

• Bug修復(fù)

• 各端

• AMD64

• RISC-V

• Linux

• Windows

• iOS系統(tǒng)

• FreeBSD

• 工具類

• 模糊測(cè)試

• Go命令

• Gofmt

• Vet

• Runtime

• 編譯器

• 鏈接器

• Bootstrap

• 核心庫(kù)

• 新的debug/buildinfo包

• 新的net/netip包

• TLS 1.0和1.1默認(rèn)在客戶端禁用

• 拒絕 SHA-1 證書(shū)

• 對(duì)庫(kù)的細(xì)微改動(dòng)

Go 1.18簡(jiǎn)介

最新的Go版本，即1.18版，是一個(gè)重要的版本，包括對(duì)語(yǔ)言、工具鏈的實(shí)現(xiàn)、運(yùn)行時(shí)和庫(kù)的改變。Go 1.18 在Go 1.17^[1]的七個(gè)月后到來(lái)。一如既往，該版本保持了 Go 1的兼容性承諾^[2]。我們期望幾乎所有的Go程序都能像以前一樣繼續(xù)編譯和運(yùn)行。

語(yǔ)言的變化

泛型

Go 1.18 包括類型參數(shù)提案^[3]所描述的泛型功能。這包括對(duì)語(yǔ)言的主要 - 但完全向后兼容的改變。

這些新的語(yǔ)言變化需要大量的新代碼，這些代碼還沒(méi)有在生產(chǎn)環(huán)境中進(jìn)行過(guò)大量的測(cè)試。這只會(huì)隨著越來(lái)越多的人編寫(xiě)和使用泛型代碼而發(fā)生。我們相信這個(gè)功能實(shí)現(xiàn)得很好，質(zhì)量很高。然而，與Go的大多數(shù)方面不同，我們無(wú)法用現(xiàn)實(shí)世界的經(jīng)驗(yàn)來(lái)支持這一信念。因此，雖然我們鼓勵(lì)在有意義的地方使用泛型，但在生產(chǎn)中部署泛型代碼時(shí)請(qǐng)適當(dāng)謹(jǐn)慎。

雖然我們相信新的語(yǔ)言特性設(shè)計(jì)得很好，而且規(guī)定得很清楚，但我們有可能犯了錯(cuò)誤。我們想強(qiáng)調(diào)的是Go 1 的兼容性保證^[4]說(shuō)："如果有必要解決規(guī)范中的不一致或不完整，解決這個(gè)問(wèn)題可能會(huì)影響現(xiàn)有程序的意義或合法性。我們保留解決此類問(wèn)題的權(quán)利，包括更新實(shí)現(xiàn)方式"。它還說(shuō)："如果一個(gè)編譯器或庫(kù)有一個(gè)違反規(guī)范的bug，如果這個(gè)bug被修復(fù)，一個(gè)依賴這個(gè)bug行為的程序可能會(huì)被破壞。我們保留修復(fù)這種錯(cuò)誤的權(quán)利"。換句話說(shuō)，有可能會(huì)有一些使用泛型的代碼在1.18版本中可以使用，但在以后的版本中會(huì)被破壞。我們不計(jì)劃也不期望做任何這樣的改變。然而，在未來(lái)的版本中，由于我們今天無(wú)法預(yù)見(jiàn)的原因，破壞1.18版本的程序可能成為必要。我們將盡可能地減少任何這樣的破壞，但我們不能保證破壞會(huì)是零。

下面是一個(gè)最明顯的變化清單。如需更全面的概述，請(qǐng)參見(jiàn) 提案^[5]。詳情請(qǐng)見(jiàn)語(yǔ)言規(guī)范^[6]。

• 函數(shù)^[7]和 類型聲明^[8] 的語(yǔ)法 現(xiàn)在接受了 類型參數(shù)^[9]。
• 參數(shù)化的函數(shù)和類型可以通過(guò)在它們后面加上方括號(hào)中的類型參數(shù)列表來(lái)進(jìn)行實(shí)例化。
• 在 操作符和標(biāo)點(diǎn)符號(hào)^[10]中加入了新的標(biāo)記~。
• 接口類型^[11] 的語(yǔ)法 現(xiàn)在允許嵌入任意類型（不僅僅是接口的類型名）以及union和~T類型元素。這樣的接口只能用作類型約束。接口現(xiàn)在定義了一組類型以及一組方法。
• 新的 預(yù)聲明標(biāo)識(shí)符^[12] any是空接口的別名。它可以用來(lái)代替 interface{}.
• 新的 預(yù)聲明標(biāo)識(shí)符^[13] comparable是一個(gè)接口，它表示所有類型的集合，可以使用 == 或 != 進(jìn)行比較。它只能作為（或嵌入）類型約束使用。

有三個(gè)使用泛型的實(shí)驗(yàn)性包可能是有用的。這些包在x/exp庫(kù)中；它們的API不在Go 1的保證范圍內(nèi)，隨著我們對(duì)泛型的經(jīng)驗(yàn)積累，可能會(huì)發(fā)生變化。

• `golang.org/x/exp/constraints`^[14]

對(duì)泛型代碼有用的約束條件，例如 `constraints.Ordered`^[15].

• `golang.org/x/exp/slices`^[16]

對(duì)任何元素類型的切片進(jìn)行操作的泛型函數(shù)的集合。

• `golang.org/x/exp/maps`^[17]

一組泛型函數(shù)，可以對(duì)任何鍵或元素類型的map進(jìn)行操作。

目前的泛型實(shí)現(xiàn)有以下已知的限制。

• Go編譯器不能處理泛型函數(shù)或方法中的類型聲明。我們希望在 Go 1.19 中提供對(duì)該功能的支持。

• Go編譯器不接受預(yù)先聲明的函數(shù)real、imag和complex的參數(shù)類型的參數(shù)。我們希望在 Go 1.19 中取消這一限制。

• Go編譯器只支持在參數(shù)類型為P的值x上調(diào)用方法m，如果m是由P的約束接口明確聲明的。同樣，方法值x.m和方法表達(dá)式P.m也只有在P明確聲明了m的情況下才會(huì)被支持，盡管由于P中的所有類型都實(shí)現(xiàn)了m，m可能在P的方法集中。我們希望在Go 1.19中取消這一限制。

• Go編譯器不支持訪問(wèn)結(jié)構(gòu)字段x.f，其中x是類型參數(shù)類型，即使類型參數(shù)的類型集中的所有類型都有字段f。我們可能會(huì)在Go 1.19中取消這一限制。

• 不允許將類型參數(shù)或指向類型參數(shù)的指針嵌入結(jié)構(gòu)體類型中的未命名字段。同樣地，在接口類型中嵌入類型參數(shù)也是不允許的。目前還不清楚這些是否會(huì)被允許。

• 有一個(gè)以上術(shù)語(yǔ)的聯(lián)合元素不能包含一個(gè)具有非空方法集的接口類型。這是否會(huì)被允許，目前還不清楚。

泛型也代表了Go生態(tài)系統(tǒng)的一個(gè)巨大變化。雖然我們已經(jīng)更新了幾個(gè)支持泛型的核心工具，但還有很多事情要做。剩下的工具、文檔和庫(kù)都需要時(shí)間來(lái)趕上這些語(yǔ)言的變化。

Bug修復(fù)

Go 1.18編譯器現(xiàn)在可以正確地告告declared but not used在函數(shù)字面內(nèi)設(shè)置但從未使用的變量的聲明但未使用錯(cuò)誤。在 Go 1.18 之前，編譯器在這種情況下不會(huì)報(bào)告錯(cuò)誤。這修復(fù)了長(zhǎng)期存在的編譯器問(wèn)題 #8560^[18]。由于這一變化，（可能是不正確的）程序可能無(wú)法再編譯了。必要的修正是簡(jiǎn)單直接的：如果程序確實(shí)不正確，就修正它，或者使用違規(guī)的變量，例如把它賦值給空白標(biāo)識(shí)符_。由于go vet總是指出這個(gè)錯(cuò)誤，受影響的程序數(shù)量可能非常小。

Go 1.18 編譯器現(xiàn)在報(bào)告說(shuō)，當(dāng)把'1' << 32'等rune常量表達(dá)式作為參數(shù)傳給預(yù)先聲明的函數(shù) print 和 println 時(shí)，會(huì)出現(xiàn)溢出，這與用戶定義的函數(shù)的行為一致。在Go 1.18之前，編譯器在這種情況下并不報(bào)錯(cuò)，而是默默地接受這種常量參數(shù)，如果它們適合于int64。由于這一變化，（可能是不正確的）程序可能無(wú)法再編譯了。必要的修正是很簡(jiǎn)單直接的：如果程序確實(shí)不正確，就修正它，或者明確地將違規(guī)的參數(shù)轉(zhuǎn)換為正確的類型。由于 go vet 總是指出這個(gè)錯(cuò)誤，受影響的程序數(shù)量可能非常少。

各端

AMD64

Go 1.18 引入了新的 GOAMD64 環(huán)境變量，它可以在編譯時(shí)選擇 AMD64 架構(gòu)的最小目標(biāo)版本。允許的值是 v1、v2、v3 或 v4。每一個(gè)更高的級(jí)別都需要并利用額外的處理器特性。詳細(xì)的描述可以在這里^[19]找到。

GOAMD64環(huán)境變量的默認(rèn)值是v1。

RISC-V

Linux 上的 64 位 RISC-V 架構(gòu)（linux/riscv64 ）現(xiàn)在支持 c-archive 和 c-shared 構(gòu)建模式。

Linux

Go 1.18 需要 Linux 內(nèi)核版本 2.6.32 或更高版本。

Windows

windows/arm 和 windows/arm64 ?現(xiàn)在支持非合作性搶占，從而使所有四個(gè) Windows端都具備了這種能力，這有望解決在調(diào)用 Win32 函數(shù)時(shí)遇到的長(zhǎng)時(shí)間阻塞的微妙錯(cuò)誤。

iOS系統(tǒng)

在 iOS (ios/arm64 ) 和基于 AMD64 的 macOS (ios/amd64) 上運(yùn)行的 iOS 模擬器上，Go 1.18 現(xiàn)在需要 iOS 12 或更高版本；對(duì)以前版本的支持已經(jīng)停止了。

FreeBSD

Go 1.18 是在 FreeBSD 11.x 上支持的最后一個(gè)版本，該版本已經(jīng)達(dá)到了生命末期。Go 1.19 將需要 FreeBSD 12.2+ 或 FreeBSD 13.0+。FreeBSD 13.0+ 將需要一個(gè)設(shè)置了 COMPAT_FREEBSD12 選項(xiàng)的內(nèi)核（這是默認(rèn)的）。

工具類

模糊測(cè)試

Go 1.18 包含了 fuzzing 提案所描述的 fuzzing 實(shí)現(xiàn)。

請(qǐng)參閱 fuzzing 頁(yè)面^[20]以開(kāi)始使用。

請(qǐng)注意，fuzzing 會(huì)消耗大量?jī)?nèi)存，在運(yùn)行時(shí)可能會(huì)影響機(jī)器的性能。 還要注意的是，模糊引擎在運(yùn)行時(shí)將擴(kuò)大測(cè)試范圍的數(shù)值寫(xiě)入$GOCACHE/fuzz內(nèi)的模糊緩存目錄。目前對(duì)寫(xiě)入模糊緩存的文件數(shù)量或總字節(jié)數(shù)沒(méi)有限制，所以它可能會(huì)占用大量的存儲(chǔ)空間（可能是幾個(gè)GB）。

Go命令

go get

go get不再以模塊感知模式構(gòu)建或安裝軟件包?，F(xiàn)在，go get專門用于調(diào)整go.mod中的依賴關(guān)系。有效地，-d 標(biāo)志總是被啟用。要在當(dāng)前模塊的上下文之外安裝一個(gè)可執(zhí)行文件的最新版本，使用 go install example.com/cmd@latest。任何版本的查詢^[21]都可以用來(lái)代替最新版本latest。這種形式的 go install 是在 Go 1.16 中添加的，因此支持舊版本的項(xiàng)目可能需要同時(shí)提供 go install 和 go get 的安裝說(shuō)明。go get 現(xiàn)在在模塊外使用時(shí)報(bào)告錯(cuò)誤，因?yàn)闆](méi)有 go.mod 文件需要更新。在 GOPATH 模式下（GO111MODULE=off），go get 仍然像以前一樣構(gòu)建和安裝軟件包。

自動(dòng)更新go.mod和go.sum

go mod graph、go mod vendor、go mod verify和go mod why子命令不再自動(dòng)更新go.mod和go.sum文件。(這些文件可以通過(guò)go get、go mod tidy或go mod download明確更新）。

go version

go 命令現(xiàn)在會(huì)在二進(jìn)制文件中嵌入版本控制信息。它包括當(dāng)前簽出的修訂版、提交時(shí)間，以及一個(gè)指示是否存在已編輯或未跟蹤文件的標(biāo)志。 如果go命令是在Git、Mercurial、Fossil或Bazaar倉(cāng)庫(kù)的一個(gè)目錄中調(diào)用的，并且主包和其包含的主模塊在同一個(gè)倉(cāng)庫(kù)中，則會(huì)嵌入版本控制信息。這個(gè)信息可以用標(biāo)志-buildvcs=false省略。

此外，go命令還嵌入了關(guān)于構(gòu)建的信息，包括構(gòu)建和工具標(biāo)簽（用-tags設(shè)置），編譯器、匯編器和鏈接器的標(biāo)志（如-gcflags），是否啟用了cgo，如果啟用了，cgo環(huán)境變量的值（如CGO_CFLAGS）。VCS和構(gòu)建信息都可以用go version -m文件或runtime/debug.ReadBuildInfo（針對(duì)當(dāng)前運(yùn)行的二進(jìn)制文件）或新的debug/buildinfo包與模塊信息一起讀取。

嵌入的構(gòu)建信息的底層數(shù)據(jù)格式會(huì)隨著新的go版本的發(fā)布而改變，所以舊版本的go可能無(wú)法處理新版本的go所產(chǎn)生的構(gòu)建信息。要從用go 1.18構(gòu)建的二進(jìn)制文件中讀取版本信息，請(qǐng)使用go版本命令和go 1.18以上版本的debug/buildinfo包。

go mod download

如果主模塊的 go.mod 文件指定了 go 1.17 或更高版本，go mod download 不帶參數(shù)，現(xiàn)在只下載主模塊的 go.mod 文件中明確要求的模塊的源代碼。(在 go 1.17 或更高版本的模塊中，這組模塊已經(jīng)包括了構(gòu)建主模塊中的包和測(cè)試所需的所有依賴項(xiàng))。要想同時(shí)下載跨平臺(tái)依賴的源代碼，請(qǐng)使用go mod download all。

go mod vendor

go mod vendor 子命令現(xiàn)在支持 -o 標(biāo)志來(lái)設(shè)置輸出目錄。(當(dāng)使用 -mod=vendor 加載軟件包時(shí)，其他 go 命令仍然從模塊根部的 vendor 目錄讀取，所以這個(gè)標(biāo)志主要用于需要收集軟件包源代碼的第三方工具。)

go mod tidy

go mod tidy 命令現(xiàn)在在 go.sum 文件中為那些需要源代碼的模塊保留了額外的校驗(yàn)和，以驗(yàn)證每個(gè)導(dǎo)入的軟件包在構(gòu)建列表^[22]中只由一個(gè)模塊提供。因?yàn)檫@種情況很罕見(jiàn)，而且不應(yīng)用它就會(huì)導(dǎo)致構(gòu)建錯(cuò)誤，所以這一變化不以主模塊的go.mod文件中的go版本為條件。

go work

go 命令現(xiàn)在支持 "工作區(qū) "模式。 如果在工作目錄或父目錄中發(fā)現(xiàn)go.work文件，或者使用GOWORK環(huán)境變量指定一個(gè)，它將使go命令進(jìn)入工作區(qū)模式。在工作區(qū)模式下，go.work文件將被用來(lái)確定作為模塊解析根的一組主模塊，而不是使用通常找到的go.mod文件來(lái)指定單一的主模塊。更多信息見(jiàn)go work文檔。

go build -asan

go build命令和相關(guān)命令現(xiàn)在支持一個(gè)-asan標(biāo)志，能夠與用AddressSanitizer（C編譯器選項(xiàng)-fsanitize=address）編譯的C（或C++）代碼互操作。

go test

go 命令現(xiàn)在支持額外的命令行選項(xiàng)，用于上述新的模糊測(cè)試支持。

go test支持 -fuzz, -fuzztime, 和 -fuzzminimizetime 選項(xiàng)。關(guān)于這些選項(xiàng)的文檔請(qǐng)參見(jiàn) go help testflag。go clean 支持 -fuzzcache 選項(xiàng)。文檔見(jiàn)go help clean。

//go:build line

Go 1.17 引入了 //go:build ，作為一種更易讀的方式來(lái)寫(xiě)構(gòu)建約束，而不是 // +build 。從Go 1.17開(kāi)始，gofmt增加了//go:build行來(lái)匹配現(xiàn)有的+build行，并保持它們的同步，而go vet則在它們不同步的時(shí)候進(jìn)行診斷。

由于Go 1.18的發(fā)布標(biāo)志著對(duì)Go 1.16的支持結(jié)束，所有支持的Go版本現(xiàn)在都能理解//go:build行。在Go 1.18中，go fix現(xiàn)在可以刪除在go.mod文件中聲明go 1.17或更高版本的模塊中現(xiàn)已被淘汰的//+build行。

更多信息，請(qǐng)參見(jiàn) https://go.dev/design/draft-gobuild。

Gofmt

gofmt 現(xiàn)在可以并發(fā)地讀取和格式化輸入文件，其內(nèi)存限制與 GOMAXPROCS 成正比。在有多個(gè) CPU 的機(jī)器上，gofmt 現(xiàn)在應(yīng)該會(huì)明顯加快。

Vet

泛型更新

vet工具已更新以支持泛型代碼。在大多數(shù)情況下，只要在非泛型代碼中用其類型集中的類型替換類型參數(shù)后，它就會(huì)報(bào)告泛型代碼的錯(cuò)誤。例如，在以下情況下，vet會(huì)報(bào)告一個(gè)格式錯(cuò)誤

func?Print[T?~int|~string](t?T?"T?~int|~string")?{
?fmt.Printf("%d",?t)
}

因?yàn)樗鼘⒃?code style="font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">Print[string]的非泛型等價(jià)物中報(bào)告一個(gè)格式錯(cuò)誤。

func?PrintString(x?string)?{
?fmt.Printf("%d",?x)
}

現(xiàn)有檢查器的精度改進(jìn)

cmd/vet檢查器、copylock、printf、sortslice、testinggoroutine和tests都有適度的精度改進(jìn)，以處理額外的代碼模式。這可能會(huì)導(dǎo)致現(xiàn)有軟件包中出現(xiàn)新的報(bào)告錯(cuò)誤。例如，printf檢查器現(xiàn)在跟蹤由串聯(lián)字符串常量創(chuàng)建的格式化字符串。所以vet會(huì)在以下情況下報(bào)告一個(gè)錯(cuò)誤。

?// fmt.Printf 格式化指令?%d 被傳遞給 Println。
??fmt.Println("%d?"+`?≡x?(mod?2)`+"\n",?x%2)

Runtime

垃圾回收器現(xiàn)在在確定運(yùn)行頻率時(shí)包括垃圾回收器工作的非堆源（例如堆棧掃描）。因此，當(dāng)這些來(lái)源很重要時(shí)，垃圾回收器的開(kāi)銷就更容易預(yù)測(cè)。對(duì)于大多數(shù)應(yīng)用程序來(lái)說(shuō)，這些變化可以忽略不計(jì)；然而，一些Go應(yīng)用程序現(xiàn)在可能使用更少的內(nèi)存，而在垃圾回收上花費(fèi)更多的時(shí)間，或者相反，比以前更多。預(yù)定的解決方法是在必要時(shí)對(duì)GOGC進(jìn)行調(diào)整。

運(yùn)行時(shí)現(xiàn)在更有效地將內(nèi)存返回到操作系統(tǒng)，并因此被調(diào)整為更積極地工作。

Go 1.17總體上改進(jìn)了堆棧跟蹤中參數(shù)的格式，但對(duì)于以寄存器傳遞的參數(shù)可能會(huì)打印出不準(zhǔn)確的值。Go 1.18中對(duì)此進(jìn)行了改進(jìn)，在每個(gè)可能不準(zhǔn)確的值后面打印一個(gè)問(wèn)號(hào)？

內(nèi)置函數(shù)append在決定必須分配一個(gè)新的底層數(shù)組時(shí)，現(xiàn)在使用了一個(gè)稍有不同的公式來(lái)增長(zhǎng)一個(gè)切片。新的公式不太容易出現(xiàn)分配行為的突然轉(zhuǎn)變。

編譯器

Go 1.17 實(shí)現(xiàn)了一種新的方法，即在選定的操作系統(tǒng)上，在 64 位 x86 架構(gòu)上使用寄存器而不是堆棧傳遞函數(shù)參數(shù)和結(jié)果。Go 1.18擴(kuò)展了支持的平臺(tái)，包括64位ARM（GOARCH=arm64）、大端和小端 64位PowerPC（GOARCH=ppc64，ppc64le），以及所有操作系統(tǒng)上的64位x86架構(gòu)（GOARCH=amd64）。在64位ARM和64位PowerPC系統(tǒng)上，基準(zhǔn)測(cè)試顯示典型的性能提升10%或更多。

正如 Go 1.17 發(fā)布說(shuō)明中所提到的，這一變化不影響任何安全 Go 代碼的功能，并且旨在對(duì)大多數(shù)匯編代碼沒(méi)有影響。更多細(xì)節(jié)請(qǐng)參見(jiàn) Go 1.17 發(fā)行說(shuō)明^[23]。

編譯器現(xiàn)在可以內(nèi)聯(lián)包含range循環(huán)或標(biāo)記的 for 循環(huán)的函數(shù)。

新的 -asan 編譯器選項(xiàng)支持新的 go 命令 -asan 選項(xiàng)。

由于編譯器的類型檢查器被全部替換為支持泛型，一些錯(cuò)誤信息現(xiàn)在可能使用與以前不同的措辭。在某些情況下，Go 1.18之前的錯(cuò)誤信息提供了更多的細(xì)節(jié)或以更有幫助的方式來(lái)表述。我們打算在Go 1.19中解決這些情況。

由于編譯器中與支持泛型有關(guān)的變化，Go 1.18的編譯速度可能比Go 1.17的編譯速度大約慢15%。編譯后的代碼的執(zhí)行時(shí)間不受影響。我們打算在Go 1.19中提高編譯器的速度。

鏈接器

鏈接器發(fā)出的重定位要少得多^[24]。因此，大多數(shù)代碼庫(kù)的鏈接速度會(huì)更快，需要更少的內(nèi)存來(lái)鏈接，并生成更小的二進(jìn)制文件。處理 Go 二進(jìn)制文件的工具應(yīng)使用 Go 1.18 的 debug/gosym 包來(lái)透明地處理新舊二進(jìn)制文件。

新的 -asan 鏈接器選項(xiàng)支持新的 go 命令 -asan 選項(xiàng)。

Bootstrap

當(dāng)從源代碼構(gòu)建 Go 版本且未設(shè)置 GOROOT_BOOTSTRAP 時(shí)，以前的 Go 版本會(huì)在目錄 $HOME/go1.4（Windows 上為 %HOMEDRIVE%HOMEPATH%\go1.4）中尋找 Go 1.4 或更高版本的引導(dǎo)工具鏈。Go現(xiàn)在首先尋找$HOME/go1.17或$HOME/sdk/go1.17，然后再返回到$HOME/go1.4。我們打算在 Go 1.19 中要求使用 1.17 或更高版本的引導(dǎo)程序，這一變化應(yīng)使過(guò)渡更加順利。詳情請(qǐng)見(jiàn)go.dev/issue/44505^[25]。

核心庫(kù)

新的debug/buildinfo包

新的debug/buildinfo包提供了對(duì)模塊版本、版本控制信息以及嵌入到go命令所構(gòu)建的可執(zhí)行文件中的構(gòu)建標(biāo)志的訪問(wèn)。同樣的信息也可以通過(guò)當(dāng)前運(yùn)行的二進(jìn)制文件的runtime/debug.ReadBuildInfo和命令行上的go version -m獲得。

新的net/netip包

新的net/netip包定義了一個(gè)新的IP地址類型，Addr。與現(xiàn)有的 net.IP 類型相比，netip.Addr 類型占用更少的內(nèi)存，是不可變的，并且是可比較的，因此它支持 == 并可以作為一個(gè)map鍵使用。

除了 Addr 之外，該包還定義了 AddrPort，代表一個(gè) IP 和端口，以及 Prefix，代表一個(gè)網(wǎng)絡(luò) CIDR 前綴。

該包還定義了幾個(gè)函數(shù)來(lái)創(chuàng)建和檢查這些新類型。AddrFrom4, AddrFrom16, AddrFromSlice, AddrPortFrom, IPv4Unspecified, IPv6LinkLocalAllNodes, IPv6Unspecified, MustParseAddr, MustParseAddrPort, MustParsePrefix, ParseAddr, ParseAddrPort, ParsePrefix, PrefixFrom。

net包包括與現(xiàn)有方法平行的新方法，但返回netip.AddrPort而不是更重的net.IP或*net.UDPAddr類型。Resolver.LookupNetIP, UDPConn.ReadFromUDPAddrPort, UDPConn.ReadMsgUDPAddrPort, UDPConn.WriteToUDPAddrPort, UDPConn.WriteMsgUDPAddrPort。新的UDPConn方法支持無(wú)內(nèi)存分配的I/O。

net包現(xiàn)在還包括在現(xiàn)有的TCPAddr/UDPAddr類型和netip.AddrPort之間轉(zhuǎn)換的函數(shù)和方法：TCPAddrFromAddrPort, UDPAddrFromAddrPort, TCPAddr.AddrPort, UDPAddr.AddrPort。

TLS 1.0和1.1默認(rèn)在客戶端禁用

如果沒(méi)有設(shè)置Config.MinVersion，現(xiàn)在默認(rèn)為客戶端連接的TLS 1.2。任何安全的最新服務(wù)器都應(yīng)該支持TLS 1.2，而且瀏覽器從2020年開(kāi)始就要求它。通過(guò)將Config.MinVersion設(shè)置為VersionTLS10，仍然支持TLS 1.0和1.1。服務(wù)器端的默認(rèn)值在TLS1.0時(shí)保持不變。

通過(guò)設(shè)置GODEBUG=tls10default=1環(huán)境變量，可以暫時(shí)將默認(rèn)值恢復(fù)為TLS 1.0。這個(gè)選項(xiàng)將在Go 1.19中被移除。

拒絕 SHA-1 證書(shū)

crypto/x509現(xiàn)在將拒絕使用 SHA-1 哈希函數(shù)簽名的證書(shū)。這并不適用于自簽的根證書(shū)。自2017年以來(lái)，針對(duì)SHA-1的實(shí)際攻擊已經(jīng)被證明，自2015年以來(lái)，公開(kāi)信任的證書(shū)頒發(fā)機(jī)構(gòu)已經(jīng)不再頒發(fā)SHA-1證書(shū)。

這可以通過(guò)設(shè)置GODEBUG=x509sha1=1環(huán)境變量暫時(shí)恢復(fù)。這個(gè)選項(xiàng)將在Go 1.19中被移除。

對(duì)庫(kù)的細(xì)微改動(dòng)

這里生態(tài)君對(duì)幾個(gè)覺(jué)得重要常用的包的改動(dòng)做了翻譯。

像往常一樣，在考慮到Go 1的兼容性的前提下，對(duì)庫(kù)進(jìn)行了各種細(xì)微的修改和更新。

bufio

新的Writer.AvailableBuffer方法返回一個(gè)空的緩沖區(qū)，其容量可能不是空的，用于類似append的API。在追加之后，該緩沖區(qū)可以提供給后續(xù)的Write調(diào)用，并可能避免任何復(fù)制。

Reader.Reset和Writer.Reset方法在對(duì)空緩沖區(qū)的對(duì)象調(diào)用時(shí)，現(xiàn)在使用默認(rèn)的緩沖區(qū)大小。

bytes

新的Cut函數(shù)將一個(gè)[]byte通過(guò)分隔符切割。它可以取代并簡(jiǎn)化許多Index、IndexByte、IndexRune和SplitN的常見(jiàn)用法。

Trim、TrimLeft和TrimRight現(xiàn)在是無(wú)內(nèi)存分配的，特別是對(duì)于小的ASCII切割集，速度可提高10倍。

Title函數(shù)現(xiàn)在已經(jīng)廢棄了。它不能處理Unicode標(biāo)點(diǎn)符號(hào)和特定語(yǔ)言的大小寫(xiě)規(guī)則，并且被golang.org/x/text/cases包所取代。

go/ast

根據(jù)提案，為支持參數(shù)化函數(shù)和類型，對(duì) go/ast 和 go/token 增加了以下內(nèi)容，并對(duì) go/ast 包進(jìn)行了補(bǔ)充。

• FuncType 和 TypeSpec 節(jié)點(diǎn)有一個(gè)新的字段 TypeParams 來(lái)保存類型參數(shù)（如果有的話）。
• 新的表達(dá)式節(jié)點(diǎn)IndexListExpr表示具有多個(gè)索引的索引表達(dá)式，用于具有一個(gè)以上顯式類型參數(shù)的函數(shù)和類型實(shí)例化。

go/types

新的Config.GoVersion字段設(shè)置接受的Go語(yǔ)言版本。

根據(jù)提案，為支持類型參數(shù)，在 go/types 包中增加了以下內(nèi)容。

• 增加了新的 TypeParam 類型、工廠函數(shù) NewTypeParam 和相關(guān)方法來(lái)表示類型參數(shù)。

• 新類型 TypeParamList 保存一個(gè)類型參數(shù)的列表。

• 新類型 TypeList 保存一個(gè)類型的列表。

• 新的工廠函數(shù)NewSignatureType分配了一個(gè)帶有（receiver或函數(shù)）類型參數(shù)的簽名。為了訪問(wèn)這些類型參數(shù)，Signature類型有兩個(gè)新方法Signature.RecvTypeParams和Signature.TypeParams。

• Named類型有四個(gè)新的方法。Named.Origin用于獲取實(shí)例化類型的原始參數(shù)化類型，Named.TypeArgs和Named.TypeParams用于獲取實(shí)例化或參數(shù)化類型的類型參數(shù)或類型參數(shù)，Named.SetTypeParams用于設(shè)置類型參數(shù)（例如，當(dāng)導(dǎo)入一個(gè)命名類型時(shí)，由于可能的循環(huán)周期，命名類型的分配和類型參數(shù)的設(shè)置不能同時(shí)進(jìn)行）。

• interface類型有四個(gè)新方法。Interface.IsComparable和Interface.IsMethodSet用于查詢接口定義的類型集的屬性，Interface.MarkImplicit和Interface.IsImplicit用于設(shè)置和測(cè)試接口是否是圍繞類型約束字的隱式接口。

• 增加了新的類型Union和Term、工廠函數(shù)NewUnion和NewTerm以及相關(guān)方法，以表示接口中的類型集。

• 新的函數(shù)Instantiate實(shí)例化了一個(gè)參數(shù)化的類型。

• 新的Info.Instances映射通過(guò)新的Instance類型記錄函數(shù)和類型實(shí)例化。

• 增加了新的 ArgumentError 類型和相關(guān)方法，以表示與類型參數(shù)有關(guān)的錯(cuò)誤。

• 增加了新的 Context 類型和工廠函數(shù) NewContext，以便通過(guò)新的 Config.Context 字段，在類型檢查的包之間共享相同的類型實(shí)例。

謂詞 AssignableTo、ConvertibleTo、Implements、Identical、IdenticalIgnoreTags 和 AssertableTo 現(xiàn)在也適用于屬于或包含泛型接口的參數(shù)，即在 Go 代碼中只能作為類型約束使用的接口。請(qǐng)注意，AssignableTo、ConvertibleTo、Implements 和 AssertableTo 的行為在參數(shù)為非實(shí)例化泛型的情況下是未定義的，如果第一個(gè)參數(shù)是泛型接口，AssertableTo 是未定義的。

reflect

新的Value.SetIterKey和Value.SetIterValue方法使用一個(gè)map迭代器作為源來(lái)設(shè)置一個(gè)Value。它們等同于Value.Set(iter.Key())和Value.Set(iter.Value())，但做的內(nèi)存分配較少。

新的 Value.UnsafePointer方法將Value的值作為一個(gè)unsafe.Pointer返回。這允許調(diào)用者從Value.UnsafeAddr和Value.Pointer遷移，以消除在調(diào)用點(diǎn)執(zhí)行uintptr到unsafe.Pointer轉(zhuǎn)換的需要（因?yàn)?code style="font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(30, 107, 184);background-color: rgba(27, 31, 35, 0.05);font-family: "Operator Mono", Consolas, Monaco, Menlo, monospace;word-break: break-all;">unsafe.Pointer規(guī)則要求）。

新的MapIter.Reset方法改變了它的receiver，在不同的map上進(jìn)行迭代。使用MapIter.Reset可以對(duì)許多map進(jìn)行無(wú)內(nèi)存分配的迭代。

一些方法（Value.CanInt, Value.CanUint, Value.CanFloat, Value.CanComplex）被添加到Value中以測(cè)試轉(zhuǎn)換是否安全。

Value.FieldByIndexErr 已被添加到 Value.FieldByIndex 中，以避免在通過(guò)一個(gè)指向嵌入式結(jié)構(gòu)的空指針時(shí)發(fā)生panic。

reflect.Ptr 和 reflect.PtrTo 分別被重命名為 reflect.Pointer 和 reflect.PointerTo，以便與 reflect 包的其他部分保持一致。舊名稱將繼續(xù)工作，但在未來(lái)的 Go 版本中會(huì)被廢棄。

runtime/debug

BuildInfo 結(jié)構(gòu)有兩個(gè)新字段，包含關(guān)于二進(jìn)制文件如何構(gòu)建的額外信息。

• GoVersion 保存用于構(gòu)建二進(jìn)制文件的 Go 版本。
• Settings是BuildSettings結(jié)構(gòu)的一個(gè)slice，持有描述構(gòu)建過(guò)程的鍵/值對(duì)。

string

新的Cut函數(shù)將一個(gè)字符串圍繞著分隔符進(jìn)行切割。它可以取代并簡(jiǎn)化許多Index、IndexByte、IndexRune和SplitN的常見(jiàn)用法。

新的Clone函數(shù)復(fù)制了輸入字符串，而返回的克隆字符串沒(méi)有引用輸入字符串的內(nèi)存。

Trim、TrimLeft和TrimRight現(xiàn)在是0內(nèi)存分配的，特別是對(duì)于小的ASCII切割集，速度可提高10倍。

Title函數(shù)現(xiàn)在已經(jīng)廢棄了。它不能處理 Unicode 標(biāo)點(diǎn)符號(hào)和特定語(yǔ)言的大寫(xiě)規(guī)則，并且被 golang.org/x/text/cases 包所取代。

sync

新的方法Mutex.TryLock、RWMutex.TryLock和RWMutex.TryRLock，將在當(dāng)前未持有鎖的情況下獲取鎖。

testing

增加了-run和 -bench 參數(shù)中的 / 的優(yōu)先級(jí)。A/B|C/D 曾被視為 A/(B|C)/D，現(xiàn)在被視為 (A/B)|(C/D)。

如果-run選項(xiàng)沒(méi)有選擇任何test，-count選項(xiàng)將被忽略。這可能會(huì)改變現(xiàn)有測(cè)試的行為，在不太可能的情況下，一個(gè)測(cè)試改變了每次運(yùn)行測(cè)試函數(shù)本身時(shí)的子測(cè)試集。

新的 testing.F 類型被上述新的 fuzzing 支持所使用。測(cè)試現(xiàn)在也支持命令行選項(xiàng) -test.fuzz, -test.fuzztime, 和 -test.fuzzminimizetime。

參考資料