大家好，我是煎魚。

在五一假期的第一天，Go 核心團隊也沒有閑著，@Russ Cox 直接在官方博客發布了《Evolving the Go Standard Library with math/rand/v2》這篇文章。

圖片

其部分內容是對本次做 math/rand/v2 標準庫升級的內容進行再度陳述，有興趣的小伙伴可以閱讀我之前寫的《Go1.22 新特性：新的 math/rand/v2 庫，更快更標準！》，能夠知悉全貌。

本文的重點是對另外的 Go 標準庫 v2 的指導思想和規劃進行分享。

之前：標準庫 v1 問題

自 Go1 在 2012 年 3 月發布以來，對標準庫的修改一直受到 Go1 的兼容性承諾的約束。

圖片

總體而言，Go1 兼容性保障對 Go 用戶來說是一個福音，它為生產系統、文檔、教程、書籍等提供了一個穩定的基石。

然而隨著時間的推移，Go 核心團隊意識和發現原始 API 中，存在著許多錯誤無法以兼容的方式修復。

包括在其他場景下，Go 的最佳實踐和約定已經發生了變化。我們需要一個可推進的計劃來做出重要的、破壞性的變更。

為此，Go 1.22 新增的 math/rand/v2 包，這是標準庫中的第一個 “v2” 包。它為 math/rand API 帶來了必要的改進。

更重要的是：它為我們如何根據需要修訂其他標準庫包樹立了榜樣。

未來：標準庫 v2 演進原則

基本準則

這項工作的目標之一是：為標準庫中所有 v2 包的處理方式建立原則和模式。

在接下來的幾個 Go 版本中，Go 核心團隊承諾不會有大量的 v2 包涌現。相反，他們將每一次只處理一個包，提高設計質量。

確保新的標準庫 v2 設定的質量標準能夠持續十年。（可能有許多包根本不需要 v2）

三個設計原則

對于那些確實需要 v2 版本的包，我們將會歸結為三個設計原則去實施。

具體如下：

1、不兼容的新版本軟件包將使用 /package/v2 作為導入路徑：就像標準庫之外的 v2 模塊一樣遵循語義導入版本化。這樣原始軟件包 v1 和 v2 軟件包就可以在一個程序中共存，這對于逐步轉換到新的應用程序接口至關重要。

2、所有更改都必須以尊重現有用法和用戶為基礎：我們絕不能引入不必要的變化，無論是對現有軟件包的不必要更改，還是必須學習的全新軟件包。在實踐中，這意味著我們要以現有軟件包為起點，只對動機明確、價值合理的軟件包進行修改。

3、v2 標準庫不能把 v1 用戶拋在后面，完全不管了。在理想情況下，v2 軟件包應能做 v1 軟件包能做的一切事情，而當 v2 發布時，v1 軟件包應被重寫為 v2 的薄封裝。這將確保現有的 v1 軟件包繼續受益于 v2 中的錯誤修復和性能優化，也保證了 v1 的兼容性。

意外考量

相較于 v1， v2 的包將會引入破壞性的變化，想讓 v1 被重寫為 v2 的薄封裝，并不總是可行的，在設計上這始終是需要慎重考慮的。

像是本次新增的 math/rand/v2，我們將 rand 中 auto-seeded v1 函數調用 v2 生成器，但由于重復性違規，我們無法共享其他代碼。最終，math/rand 改動的代碼量并不大，也不需要定期維護，因此重復是可控的。

在其他情況下，為避免重復做更多的工作可能是值得的。例如：在 encoding/json/v2 的設計（仍在進行）中，雖然默認語義和 API 都發生了變化，但軟件包提供的配置項可以實現 v1 API。

當我們最終發布 encoding/json/v2 時，encoding/json (v1) 將成為它的一個薄包裝，確保不從 v1 遷移的用戶仍能受益于 v2 中的優化和安全修復。

總結

通過閱讀本文的標準庫 v2 的設計講解，能夠感受到其實 @Russ Cox 已經對 Go 兼容性這塊做好了規劃。基本是先動 Go1 兼容性前后保障的準則，再動標準庫。同時標準庫 v2 要兼容 v1 的使用，不能直接就是完全不維護了。

這樣對于用戶的得益雖然是較大的，但對于 Go 核心團隊來講，維護的工作量和可能出現的程序意外（BUG）的概率也會變大，因為要兼容的新老場景都變多了。

不論怎么說，未來這將會出現。大家可以一起見證 Go 標準庫 v2 接下來的發展！我猜 json v2 包要快轉正了。