Go作者忍了10年的if err != nil

Go的錯誤處理寫了10年，你數過自己在代碼里敲過多少次if err != nil嗎？

一位開發者算過：一個中等規模的項目，這行代碼能出現上千次。不是業務邏輯，是機械勞動。

Go團隊對此的態度一直很明確——顯式比隱式好。但顯式的代價是：當控制流復雜起來，業務代碼會被埋進重復的錯誤檢查里。這就像你每次出門都要手動檢查門窗鎖沒鎖，鎖是對的，但檢查100次就是折磨。

最近一個名為go-opera的輕量庫在GitHub上引起討論。它不試圖推翻Go的設計哲學，而是用Result類型和鏈式調用，把錯誤處理從"填空題"變成"選擇題"。

Go的錯誤處理，到底卡在哪

go-opera的作者在文檔里列了三個具體痛點。第一個很多人沒意識到：Go函數失敗時，必須返回一個零值湊數。

這個零值通常是填充物，增加噪音，而非意義。

比如加載用戶的函數，ID為空時得返回一個空的User結構體：

func loadUser(id string) (User, error) {if id == "" {return User{}, errors.New("empty id")return User{ID: id}, nil

User{}這個空殼子從不會真正使用，但編譯器逼你寫。在復雜場景里，構造這些零值本身就是心智負擔。

第二個痛點更隱蔽：Go支持多返回值，但不支持直接傳遞。你想把parsePort的結果喂給openServer？不行，得先 unpacking。

func parsePort() (int, error) {return strconv.Atoi("8080")func openServer(port int) error {return nilfunc main() {// 編譯報錯openServer(parsePort())

函數式編程里的compose在Go里寸步難行。每個中間步驟都要打斷流程，聲明臨時變量，檢查錯誤，再繼續。代碼的"節奏感"被切得支離破碎。

第三個痛點是規模問題。當函數有多個步驟，你會看到err、err2、err3或者反復 shadow 的err：

func tooManyErrors() error {val1, err1 := errFunc1()if err1 != nil {return fmt.Errorf("step 1 failed: %w", err1)val2, err2 := errFunc2(val1)if err2 != nil {return fmt.Errorf("step 2 failed: %w", err2)// ... 重復到 step 4

另一種寫法是用同一個err變量，靠作用域 shadow：

func process() error {data, err := readFile()if err != nil {return errif err := validate(data); err != nil {return err

這是Go的慣用寫法，但閱讀成本不低。步驟一多，函數就變成了"錯誤記賬本"——業務邏輯和錯誤處理纏在一起，改一處要牽三處。

go-opera的解法：把錯誤變成"一等公民"

go-opera的核心是一個Result類型，包裹值或錯誤，但不同時存在。靈感來自Rust和EffectTS，但做了Go化的適配。

作者的原話是：「目標不是隱藏錯誤，而是讓錯誤傳播更易讀、更易組合、更少重復。」

基本用法看起來像這樣。函數返回Result而不是(value, error)對：

func loadUser(id string) result.Result[User] {if id == "" {return result.Err[User](errors.New("empty id"))return result.Ok(User{ID: id})

調用方用鏈式方法處理，不用寫if判斷：

user := loadUser("123").Map(func(u User) User { /* 轉換 */ }).Filter(func(u User) bool { /* 過濾 */ }).OrElse(func() User { /* 默認值 */ })

關鍵操作包括：Map（成功時轉換）、FlatMap（鏈式調用可能失敗的函數）、Filter（條件過濾）、OrElse（失敗時兜底）。錯誤會自動穿透，不用手動傳遞。

Do notation是另一個設計。它用閉包包裹多步操作，自動處理提前返回：

result := result.Do(func() result.Result[User] {user := result.Unwrap(loadUser("123"))config := result.Unwrap(loadConfig(user.ID))return connectServer(config)

Unwrap在Result為Err時會提前終止整個Do塊，把錯誤帶出去。寫法上像同步代碼，行為上是自動的錯誤傳播。

爭議點：這是進步還是糖衣

GitHub上的討論分成了兩派。支持方認為，go-opera在保持顯式的前提下，把機械勞動交給了庫——你仍然能看到錯誤在哪傳播，只是不用寫第1000個if err != nil。

反對方的質疑更尖銳：Result類型在Go里是運行時包裝，有內存分配開銷；鏈式調用調試時堆棧更深；團隊里有人不熟悉這個模式，代碼就變成了"方言"。

一位評論者寫道：「Go的錯誤處理是啰嗦，但所有人都用同一種方式啰嗦。引入新抽象，解決的是書寫痛苦，增加的是理解成本。」

作者對此的回應是分層使用：核心路徑用Result消除噪音，邊界處轉回原生error保持兼容。不是非此即彼，而是"在摩擦最大的地方涂潤滑油"。

性能方面，簡單benchmark顯示Result包裝在熱路徑上有輕微開銷，但作者強調這屬于"可優化的實現細節"，而非設計缺陷。

一個值得玩味的細節

go-opera的文檔里埋了一句作者的觀察：很多Go開發者其實已經在用類似模式，只是各自手寫——有的用結構體包裝，有的用panic-recover模擬，有的干脆把錯誤攢到最后一起處理。

這些"民間方案"往往不兼容、不透明、難以維護。go-opera試圖提供一個最小共識：200行代碼，零依賴，標準庫風格。

它不會進入Go標準庫，也不太可能改變Go 2的設計方向。但對于那些每天在if err != nil里掙扎的開發者，它提供了一個可以立刻用的選項——不是答案，是選擇。

你會在自己的項目里引入這種Result模式，還是繼續相信"顯式重復"本身就是一種文檔？