大家好，我是煎魚。

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

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

寫了個開頭結果陽了，現在陽康還咳嗽回來接著更。

Go1 兼容性保障

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

當然，凡事有例外，像是安全問題就是例外。

具體的完整細則如下圖：

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

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

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

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

看起來還是有板有眼的。

擴展 Go 向后兼容性

背景

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

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

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

怎么突然提起

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

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

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

有興趣的同學可以細看，考慮大多數同學可能并不關心，所以我沒有進一步展開。

現有與兼容性相關的 GODEBUG 設置包括如下：

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

擴大 Go1 兼容性保障

在新提案中，Go 將會正式確定并擴大對 GODEBUG 的使用，將根據 go.mod 中的 Go 版本號來設置對應 GODEBUG，以提供超越當前兼容性準則所保證的兼容性。

根據 go.mod 內的 go 版本設置 GODEBUG

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

新措施的具體內容如下：

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

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

會遵循以下流程規范：

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

總結

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

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

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

想當年，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