前言

“Go 的錯誤處理寫起來太繁復了?！?nbsp;—— 這是幾乎每個 Go 程序員都認可的一個觀點。

而就在最近，Go 官方發布了一篇博客文章，正式宣布：他們不會再推進任何新的錯誤處理語法提案。這也意味著，未來編寫 Go 代碼時，你依然會頻繁地寫下那句熟悉的 if err != nil { return err }。

這不僅是對一次語法糖提案的終結，更是對整個語言哲學的再確認。那么，Go 團隊為什么做出這樣的決定？我們又該如何看待這份執著？

準備好了嗎？準備一杯你最喜歡的咖啡或茶，隨著本文一探究竟吧。

三次嘗試，三次失?。篏o 錯誤處理語法的探索之路

過去七年，Go 團隊三次嘗試通過引入新語法機制，解決錯誤處理的 “重復編寫” 問題，但最終都未能落地。

第一次：2018 年的 check / handle 提案

這次提案源自 Go 2 草案，是一套完整的語法變更，目標是引入：

• check() 用于捕獲函數調用中的 error；
• handle 塊用于統一處理這些錯誤。

func printSum(a, b string) error {
    handle err { return err }         // 所有 check 失敗都跳進這里
    x := check(strconv.Atoi(a))
    y := check(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

• ?? 優點：結構清晰、統一管理錯誤路徑。
• ?? 缺點：引入新語法塊，語言學習曲線陡增，語義復雜度高，引發廣泛爭議。

最終，Go 團隊認為這套機制 太復雜了，沒能走出草案階段。

第二次：2019 年的 try() 提案

借鑒第一輪經驗，Go 團隊提出了一個更輕量的版本：try() 函數。

func printSum(a, b string) error {
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

本質上等價于：

x, err := strconv.Atoi(a)
if err != nil {
    return err
}

• ?? 優點：簡單、清晰，不引入語法塊，只是一個內置函數。
• ?? 缺點：自動 return 掩蓋控制流，不符合 Go 一貫強調的 “顯式可讀”。調試困難、理解成本高。

最終，該提案因社區反對聲音過大，被正式放棄。

第三次：2024 年的 ? 操作符提案

這一次，Go 團隊轉向更具現實基礎的設計：參考 Rust 的 ?，引入錯誤處理的后綴語法糖：

func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

遺憾的是，與其他錯誤處理方案一樣，該提案也迅速被各種評論和眾多基于個人偏好的細微調整建議所淹沒。

最后的決定：不再推進語法層的改變

三次努力，都未能獲得廣泛共識。2025 年 6 月，Go 團隊在官方博客中正式宣布：

For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.

英譯中如下：

在可預見的未來，Go 團隊將不再推進錯誤處理的語法改動。我們也將關閉所有當前或未來主要涉及語法層面的錯誤處理提案，不再進一步研究。

這個決定并非技術上沒有方案，而是出于共識缺失、成本評估、語言哲學 等多重考量。

它既是一次 現實主義的收場，也是一次對 Go 語言設計初心的堅持。

為什么 Go 團隊堅持不改？兩大核心原因解析

Go 團隊并不是不知道錯誤處理 “寫起來很重復”，甚至也不是找不到更簡潔的語法。過去七年里，他們三次親自推動提案，最后又三次親自按下終止鍵。這不是技術做不到，而是價值判斷的問題。

我們可以從兩個維度，理解 Go 團隊為什么最終選擇“不改”。

1. 沒有形成“壓倒性共識”

Go 團隊一再強調，“我們并不只是尋找一個可以工作的方案，而是一個 足夠多人愿意接受并使用的方案 ”。

但現實是：每一次提案都會引發大量 “我想要的不是這個” 的聲音——

• 有人覺得 check/handle 太復雜；
• 有人認為 try() 太自動；
• 也有人覺得 ? 符號雖然直觀，但語義仍不夠清晰。

每一次語法糖的背后，都伴隨著風格沖突、哲學分歧和無休止的 bikeshedding（無謂爭論）。Go 團隊明確指出：

“即使是我們目前看到的最佳提案，也都無法獲得壓倒性支持?！?/p>

Go 的設計哲學一直非?，F實主義：沒有共識，就不做。

2. 技術收益與代價不成正比

每一個提案背后，Go 團隊都做了原型工具鏈支持（包括編譯器、文檔、工具鏈等），但他們發現：

• 盡管語法看起來簡潔了；
• 寫代碼 可能節省幾行，
• 但 閱讀和理解的成本 卻沒有等量下降。

比如：

x := strconv.Atoi(a)?

這行代碼的確省略了 if 語句，但程序的控制流變得不再顯式，錯誤是如何返回的、被誰處理的，變成了語言隱含邏輯的一部分。Go 團隊擔心：

“語言層的魔法越多，用戶調試、閱讀、定位問題的成本就越高。”

在他們看來，Go 的優勢從來不是寫得最少，而是 看得懂、調得順、跑得穩。

后續方向：語法不變，但體驗可改

雖然 Go 團隊明確表示不會再推進錯誤處理的語法層變更，但這并不代表錯誤處理就此 “封印”。相反，改善開發體驗的空間仍然廣闊，文章中就提到了幾個重要方向：

借助庫函數減少重復代碼

Go 官方明確支持 通過標準庫增強功能，來降低錯誤處理中的重復編寫。例如：

x, err1 := strconv.Atoi(a)
y, err2 := strconv.Atoi(b)
if err := cmp.Or(err1, err2); err != nil {
    return err
}

這里使用 cmp.Or 來統一處理多個 error，減少重復判斷。這種方式保持了 Go 的語法一致性，又提升了可讀性。

強化 IDE 和工具鏈支持

博客中提出了一個很現實的方向：讓 IDE 更聰明地“隱藏冗余”。

現代 IDE（特別是配合 LLM 的智能補全）已經可以極大地簡化 err != nil 這類重復代碼的編寫，而未來的可能性還包括：

• ?? 在 IDE 中添加“隱藏 error 處理語句”的開關；
• ?? 僅在需要時展開 if err != nil 語句塊，提升閱讀流暢度；
• ?? 讓 AI 幫助我們自動生成更具上下文的錯誤信息。

這種方式不會改變語言本身，卻可能實實在在提升編寫和閱讀 Go 代碼的效率。

聚焦于錯誤處理

回到實際的錯誤處理代碼，如果我們聚焦于錯誤處理，而不是只是返回錯誤，冗長的代碼就變得無關緊要了。良好的錯誤處理通常需要在錯誤中添加額外的信息。例如，用戶調查中反復出現的評論是關于缺少與錯誤相關的堆棧跟蹤。這可以通過生成并返回增強錯誤的支持函數來解決，例如：

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", a)
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return fmt.Errorf("invalid integer: %q", b)
    }
    fmt.Println("result:", x + y)
    return nil
}

小結

盡管 Go 團隊明確表示不會再推進錯誤處理的語法層改動，但這并不意味著錯誤處理的優化空間已經封閉。通過標準庫的增強、工具鏈的改進以及更注重錯誤處理的上下文信息，開發者仍然可以在保持語言一致性的前提下，提升代碼的可讀性和開發效率。這一決定不僅體現了 Go 語言對顯式性和簡單性的堅持，也為未來的工具生態和開發體驗優化留下了更多可能性。