大家好，我是煎魚。

前段時間我們在寫 Go1.20 新特性和變更時，發(fā)現(xiàn)了一個問題有悖論。

Go1 有兼容性承諾，但如果發(fā)現(xiàn)了 BUG，會破壞兼容性。那怎么辦？是大膽修改，破壞掉，還是說設(shè)計如此，打死不改？

寫了個開頭結(jié)果陽了，現(xiàn)在陽康還咳嗽回來接著更。

Go1 兼容性保障

在 Go1 引入了 Go 兼容性保障《Go 1 and the Future of Go Programs[1]》，也就是舊版本的 Go 程序也可以在繼續(xù) Go 的新版本中正確運行。

當(dāng)然，凡事有例外，像是安全問題就是例外。

具體的完整細則如下圖：

我們常接觸到的有以下幾個：

• 安全問題：Go 規(guī)范或?qū)嵤┲械陌踩珕栴}可能會被發(fā)現(xiàn)，其解決需要破壞兼容性。將會保留解決這些安全問題的權(quán)利。
• 未指定的行為：雖然 Go 規(guī)范中嘗試明確所有已知行為，但是意料之外還是會存在一些方面是未定義的。這方面可能會出現(xiàn)問題。
• 規(guī)范錯誤：如果有必要解決規(guī)范（spec）中出現(xiàn)的不一致、不完整，將會保留解決此類問題的權(quán)利。除了安全問題，不會對規(guī)范進行不兼容的修改。
• 問題/缺陷：如果編譯器、庫有違反規(guī)范的缺陷，會保留修復(fù)這些缺陷的權(quán)利。
• 使用 import . 導(dǎo)入：如果在程序使用 import . "path"，在未來的版本中，在導(dǎo)入的包中定義的其他名字可能會與程序中定義的其他名字相沖突。我們不推薦在測試之外使用 import .，使用它可能會導(dǎo)致程序在未來的版本中無法編譯。
• 引用 unsafe 庫：導(dǎo)入 unsafe 的包可能依賴于 Go 實現(xiàn)的內(nèi)部屬性。會保留修改的權(quán)利。

Go 核心團隊自述已經(jīng)有 10+ 年的 Go1 兼容性保障的經(jīng)驗，對 Go 團隊和用戶來說都非常的有價值。

甚至近兩年，Go 團隊和業(yè)內(nèi)把 Go 的高速發(fā)展歸因于對 Go1 兼容性的保障的落地實施。

看起來還是有板有眼的。

擴展 Go 向后兼容性

背景

雖然主觀上 Go 團隊認為做的比較好，但發(fā)現(xiàn)仍然存在進行了兼容性破壞的情況。因此 Go 現(xiàn)任當(dāng)家 @Russ Cox 發(fā)起了《extending Go backward compatibility[2]》。

其認為值得擴展 Go1 的向后兼容性，以嘗試更少地破壞程序，明確地進行 GODEBUG 的設(shè)置，便于聲明變更項在何時適應(yīng)使用和控制。

簡單來講，就是 Go1 兼容性承諾給 Go 帶來了非常大的好處，要繼續(xù)擴大優(yōu)勢項，把長板拉長。

怎么突然提起

那為什么會突然想搞這事？因為 Russ Cox 最近和 Kubernetes 團隊交流，發(fā)現(xiàn)在過去的幾年里，Go 平均每年大約會有一個 Kubernetes 的破壞性變更。

其認為 Kubernetes 肯定不是一個個例。雖然每年 1 次左右的頻率并不高，但 Go 團隊在 Go1 兼容性的目標(biāo)是是 0 次。

以下是對 Kubernetes 造成重大更改的一些示例：

有興趣的同學(xué)可以細看，考慮大多數(shù)同學(xué)可能并不關(guān)心，所以我沒有進一步展開。

現(xiàn)有與兼容性相關(guān)的 GODEBUG 設(shè)置包括如下：

• GODEBUG=asyncpreemptoff=1：禁用基于信號的 Goroutine 搶占，這偶爾會發(fā)現(xiàn)操作系統(tǒng)的錯誤。
• GODEBUG=cgocheck=0：禁用運行時的 CGO 指針檢查。
• GODEBUG=cpu.<extension>=off：在運行時禁止使用某個特定的 CPU 擴展。
• GODEBUG=http2client=0：禁用客戶端的 HTTP/2。
• GODEBUG=http2server=0：禁用服務(wù)器端的 HTTP/2。
• GODEBUG=netdns=cgo：強制使用 CGO 解析器。
• GODEBUG=netdns=go：強制使用 Go DNS 解析器。

擴大 Go1 兼容性保障

在新提案中，Go 將會正式確定并擴大對 GODEBUG 的使用，將根據(jù) go.mod 中的 Go 版本號來設(shè)置對應(yīng) GODEBUG，以提供超越當(dāng)前兼容性準(zhǔn)則所保證的兼容性。

根據(jù) go.mod 內(nèi)的 go 版本設(shè)置 GODEBUG

也就是接下來將會延伸以往的 GODEBUG 配置項，擴大使用面。

新措施的具體內(nèi)容如下：

• 承諾始終為兼容性指南允許的更改添加 GODEBUG 設(shè)置，但這仍然可能會破壞大量實際程序。
• 保證 GODEBUG 設(shè)置至少持續(xù) 2 年（4 個版本）。這只是最低要求；會存在例如，例如：http2server，可能會永遠存在。
• 提供運行時/指標(biāo)計數(shù)器，可用于觀察由 GODEBUG 設(shè)置導(dǎo)致的非默認行為。如：/godebug/non-default-behavior/<name>:events。
• 根據(jù) Go modules 主模塊的 go.mod 中的 Go 版本，給 Go 應(yīng)用設(shè)置對應(yīng)的 GODEBUG 設(shè)置。注意不是當(dāng)前編譯的 Go 版本。是根據(jù) go.mod 內(nèi)的 Go 版本號。
• 允許使用以下形式的一行或多行覆蓋主包源代碼中的特定默認 GODEBUG 設(shè)置：//go:debug <name>=<value>。
• 會同步修改 go/build、go list、go version -m 等配套工具鏈的使用，確保 GODEBUG 設(shè)置能夠被顯式查看。
• 在兼容性指南中記錄這些承諾以及如何配置使用 GODEBUG。

更加具體的案例，跟現(xiàn)有的 GODEBUG 其實是類似。例如 Go1.20 引入了一個新的 GODEBUG zipinsecurepath。

會遵循以下流程規(guī)范：

• Go1.20 中默認值為 1，以保留舊的行為并允許不安全的路徑。
• Go1.21 可能會將默認值更改為 0，以開始拒絕 archive/zip 中的不安全路徑。如果是這樣，且 Go1.21 也實現(xiàn)了這個 GODEBUG 提案，那么當(dāng)使用 Go1.21 編譯的帶有 Go1.20 的模塊（go.mod）時，將繼續(xù)允許不安全的路徑。只有當(dāng)這些模塊版本更新到 Go1.21 時，它們才會開始拒絕不安全的路徑。

總結(jié)

Go 在這幾年對 Go1 兼容性保障越來越看重，在今年將會進一步加強。該提案已經(jīng)到了最終階段，很有可能會被接受，且最新評論沒有反對意見。

該提案將會加大在兼容性上 GODEBUG 的應(yīng)用，且最重要的是，將會根據(jù) go.mod 文件中的 Go 版本來調(diào)整 GODEBUG，這會是一個重大微調(diào)整。

唯一糾結(jié)的同學(xué)，主要是反饋很多 Go 開發(fā)者，不知道自己修改 go.mod 文件中的 go 版本時，會導(dǎo)致 GODEBUG 的變更，從而影響到程序，會比較隱晦。

想當(dāng)年，rsc 給 go.mod 加 go 版本號時，表示還沒想好用在哪里...我只想表示這棵樹也埋的真深。

參考資料

[1]Go 1 and the Future of Go Programs: https://go.dev/doc/go1compat

[2]extending Go backward compatibility: https://github.com/golang/go/discussions/55090