Go 清理技術債務：將刪除部分 GODEBUG 標識！
最近 Go 團隊提出了一個挺有意思的提案，說的是要系統性地清理 GODEBUG 標志。
從 Go 1.12 引入 GODEBUG 機制到現在，各種標志越來越多，維護成本也越來越高。
今天給大家分享的是 GODEBUG 標志清理的提案，以及第一批要開刀的加密相關標志。
咱們一起來看看 Go 核心團隊打算怎么處理這個技術債務。
背景
為什么會有 GODEBUG 這個設計和機制？
2012 年 3 月，Go 1 發布的時候，Go 團隊做了一個重要承諾：Go 1 兼容性保證。
簡單來說就是，符合 Go 1 規范的程序，在后續的 Go 1.x 版本中都能正常編譯和運行。這個保證可以說是 Go 語言能穩定發展的基石（也是很多同學敢于直接升版本的壓艙石）。
但問題來了，這 13 年里，Go 團隊遇到了各種安全問題和其他需要改進的地方。雖然這些改動不違反兼容性保證，但有時候確實會影響程序的行為。
為了讓開發者能平滑過渡，GODEBUG 環境變量就應運而生了。
簡單例子
舉個例子，Go 1.21 引入了 panicnil 設置：
// Go 1.20 及之前，這樣寫是可以的
func oldBehavior() {
panic(nil) // 不會報錯
}
// Go 1.21 開始，默認 panicnil=0
func newBehavior() {
panic(nil) // 運行時錯誤！
}如果你的老代碼依賴 panic(nil) 的舊行為，只需要設置 GODEBUG=panicnil=1，代碼就能像在 Go 1.20 一樣運行。
你再等有時間了再慢慢改代碼，這就給了業務和自己一個可控制的緩沖期。也不會影響升級 Go 新版本。
所產生的問題
可以看到，這個機制確實很貼心。但隨著時間推移，問題也來了：
- 標志越來越多了： 各種
GODEBUG標志越積越多，有的說要永久保留，有的說過兩年就刪，還有的壓根沒說什么時候刪。 - 維護成本高： 每個標志都代表一個分支邏輯，測試復雜度呈指數級增長。你想想，N 個標志就有 2^N 種組合，這測試怎么做？
- 可預測性差（組合復雜度）： 不同的
GODEBUG組合可能產生完全不同的行為，這讓 Go 工具鏈的行為變得難以預測。
所以今年 Go 核心團隊終于下決心，要系統性地清理這些技術債了。
GODEBUG 現有分類
Go 團隊把現有的 GODEBUG 標志分成了四種類型。
以易到難的程序進行排序：
- 第一類：已經移除的標志；
- 第二類：有明確移除日期的標志；
- 第三類：沒說永久保留，也沒給移除日期的標志；
- 第四類：明確說了永久保留的標志
接下來我們逐步介紹。
1、已經移除的標志
這類不用管了，比如 x509sha1 就已經被刪掉了（Go 1.24 刪除的）。
但為了歷史記錄，還是會在文檔里保留它們的存在：
2、有明確移除日期的標志
這類標志處理起來比較直接。比如 gotypesalias 標志，最早可以在 Go 1.27 移除：
// Go 1.22 引入的類型別名新語法
type MyAlias = SomeType
// GODEBUG=gotypesalias=0 可以回到舊行為
// 但 Go 1.27 之后這個標志就要被刪了處理流程是這樣的：
- 在到期前一個版本，把標志標記為 "已廢棄"；
- 在發布說明里宣布下個版本要刪除；
- 如果沒人強烈反對，下個版本就刪掉；
- 如果有重要反對意見，就延期一個版本再看。
3、沒說永久保留，也沒給移除日期的標志
這類標志得先分配一個移除日期。日期至少要滿足兩個條件：
- 距離現在至少半年（一個大版本周期）；
- 如果是兼容性標志，距離引入至少兩年；
比如某個 Go 1.23 引入的標志，最早也得 Go 1.25 才能提出移除。
4、明確說了永久保留的標志
這類最難搞，比如 netdns 標志：
// GODEBUG=netdns=go 強制使用 Go 的 DNS 解析器
// GODEBUG=netdns=cgo 強制使用 cgo 的 DNS 解析器
import "net"
func main() {
// 不同的 netdns 設置會影響域名解析行為
addrs, err := net.LookupHost("example.com")
// ...
}這類標志要刪除，必須提交一個詳細的提案，說明為什么要刪、什么時候刪、怎么減少影響。提案通過后，才能按第二類標志的流程走。
新提案：移除早期版本的 GODEBUG
本次提案《proposal: policy for removing GODEBUG flags[1]》里給出了具體的技術方案和處理思路。
API 變更
首先計劃要在 godebug.Setting 里加入標志狀態的標識：
type FlagStatus int
const (
Active FlagStatus = iota // 正常使用
Deprecated // 已廢棄
Removed // 已移除
)
func (*Setting) Status() FlagStatus {
// 返回當前標志的狀態
}或者也可以用兩個方法：
func (*Setting) Deprecated() bool {
// 標志是否已廢棄
}
func (*Setting) Removed() bool {
// 標志是否已移除
}這樣工具就能檢測到廢棄的標志了。
標記為廢棄
當一個標志被標記為廢棄后，各種工具都會給出警告：
// go.mod 文件里設置廢棄標志
godebug panicnil=1 // 構建工具會警告
// 測試代碼里設置廢棄標志
func TestSomething(t *testing.T) {
t.Setenv("GODEBUG", "panicnil=1") // 測試會報錯
}更進一步，可能會引入一個新的 GODEBUG 標志 deprecatedgodebug：
// GODEBUG=deprecatedgodebug=0 表示不允許設置任何廢棄標志
// 如果設置了廢棄標志，程序會 panic
func main() {
os.Setenv("GODEBUG", "panicnil=1") // 直接 panic！
}這對復雜系統特別有用，可以確保不會誤用廢棄的標志。
移除標志
標志被移除后，代碼里會把相關實現都刪掉。但考慮到外部的代碼可能還在用，所以將會支持：
- 設置成默認值：程序正常運行，只是忽略這個設置
- 設置成非默認值：直接報致命錯誤
// 假設 panicnil 已經被移除，默認值是 0
// GODEBUG=panicnil=0 -> 正常運行，忽略設置
// GODEBUG=panicnil=1 -> 致命錯誤！為了避免標志名被重復使用，所有的標志（包括已刪除的）都會保留在 internal/godebugs/table.go 里，這個可以通過程序驗證。
首批清理：加密相關標志
接下來我們看看第一批要清理的標志，這也是政策落地的首個實踐案例。
Go 安全團隊的 Filippo Valsorda 提出了 issue #75316，準備在 Go 1.27 移除一批加密相關的 GODEBUG 標志。
這些標志都是在 Go 1.22 和 Go 1.23 引入的，到 Go 1.27 時已經滿足至少保留兩年的要求。
擬移除的標志清單
一共有 6 個標志在清理名單上。
- tlsunsafeekm（Go 1.22 引入）
- tlsrsakex（Go 1.22 引入）
- tls10server（Go 1.22 引入）
- tls3des（Go 1.23 引入）
- x509keypairleaf（Go 1.23 引入）
- x509negativeserial（Go 1.23 引入）
感興趣的同學，或者有用到的可以自行查看上面的 issues 獲取進一步的信息和原因。
清理時間線
按照新的策略，這些標志的清理流程是這樣的：
1.Go 1.26：在發布說明里預告 Go 1.27 會移除這些標志
2.Go 1.26 到 Go 1.27 期間：開發者有半年時間反饋意見
3.Go 1.27：如果沒有強烈反對，正式移除這些標志
可以看到，這次清理主要針對的是已經被業界淘汰的不安全加密算法和協議。
Go 安全團隊的態度很明確：安全優先，不能為了兼容性而保留已知的安全風險。
總結
這個提案的核心思想很明確：有計劃地清理 GODEBUG 的技術債務，同時盡量減少對開發者的影響。
整個機制設計得挺周全的：
- 分類清晰，處理方式因類施策。
- 有明確的時間線和流程。
- 給開發者足夠的緩沖期。
- 保留歷史記錄避免標志名重復使用。
Go 核心團隊似乎在小心翼翼地平衡兼容性和技術債務的處理。同時也需要好好關注 Go1 向前和前后的兼容性保障承諾。
參考資料
[1] proposal: policy for removing GODEBUG flags: https://github.com/golang/go/issues/76163
