每年Go社區(qū)的“錯(cuò)誤處理大戰(zhàn)”一開打吵到最后的焦點(diǎn)幾乎都落在同一個(gè)問題上到底要不要Wrap錯(cuò)誤就拿我的團(tuán)隊(duì)來說代碼評(píng)審上最常見的一條評(píng)論就是“這里為什么沒加%w”而回復(fù)也高度統(tǒng)一“加了怕鏈太長(zhǎng)不加又怕斷鏈?！边@種擰巴其實(shí)很正?！狦o的錯(cuò)誤處理設(shè)計(jì)哲學(xué)與真實(shí)業(yè)務(wù)系統(tǒng)之間隔著太厚的膠水層語言本身只給了你一個(gè)極簡(jiǎn)接口type error interface { Error() string }可一條錯(cuò)誤從數(shù)據(jù)庫底層一路被拋出API網(wǎng)關(guān)中間還要穿過repository、service、handler好幾個(gè)層次每一層都得做一次莎士比亞式的選擇題To Wrap or Not to Wrap。這篇文章不打算站隊(duì)說“必須全部Wrap”或者“最好別Wrap”我想結(jié)合這些年寫Go的實(shí)際感受把%w、errors.Is、errors.As這些工具到底解決了什么問題、什么時(shí)候加Wrap是真的有信息增益、什么時(shí)候純屬自嗨式包裝講清楚。如果你正在為團(tuán)隊(duì)的錯(cuò)誤處理規(guī)范頭疼或者剛被代碼評(píng)審問住“這里為什么不Wrap”這篇應(yīng)該能給你一個(gè)相對(duì)可落地的判斷框架。1. 老生常談的“err ! nil”怎么就成了社區(qū)年經(jīng)貼1.1 為什么Go寧愿啰嗦也不引入try-catchGo選擇顯式錯(cuò)誤處理是設(shè)計(jì)者對(duì)程序可讀性的一種偏執(zhí)。異常機(jī)制在Java、Python、C#那套體系里非常成熟它能把“正常流程”和“錯(cuò)誤流程”分開但代價(jià)是控制流變得不那么直觀——一個(gè)throw拋出來你根本不知道它會(huì)飛到哪里中間可能被某個(gè)catch吞掉也可能一直穿到最外層。Go設(shè)計(jì)者從一開始就不喜歡這種“隱秘的控制流跳轉(zhuǎn)”他們寧愿讓你在代碼里看到滿屏的if err ! nil也不愿意讓你在log里看到一句干巴巴的Unexpected error然后對(duì)著堆棧猜是誰吞了異常。說白了Go對(duì)錯(cuò)誤的處理方式繼承自C的經(jīng)驗(yàn)錯(cuò)誤就是值它和正常數(shù)據(jù)一樣得顯式傳遞誰要用誰就得接著。函數(shù)簽名(T, error)的約定把“可能失敗”這件事寫在了類型系統(tǒng)里。很多剛轉(zhuǎn)Go的人覺得這規(guī)矩?zé)┤说矣^察下來真正讓團(tuán)隊(duì)崩潰的從來不是if err ! nil多寫了幾行而是錯(cuò)誤出來之后怎么流轉(zhuǎn)、怎么保留上下文、怎么讓上游能感知到錯(cuò)誤的“身份”。這才是每年社區(qū)爭(zhēng)論真正的火藥桶。1.2 Go 1.13把“包裝”扶正了在Go 1.13之前想給錯(cuò)誤附加上下文幾乎全靠字符串拼接fmt.Errorf(xxx: err.Error())。問題是拼完之后原始錯(cuò)誤的所有類型信息全部丟失。你不能對(duì)一個(gè)拼好的字符串調(diào)用errors.Is也不能從一串文本里掏出當(dāng)初那個(gè)*os.PathError或者sql.ErrNoRows。社區(qū)因?yàn)槭懿涣诉@個(gè)所以出現(xiàn)了github.com/pkg/errors這類庫用WithStack、Wrap的方式把堆棧和錯(cuò)誤綁在一起但問題在于每個(gè)庫的約定不同A庫返回的錯(cuò)誤到了B庫沒法統(tǒng)一處理。2019年Go 1.13正式發(fā)布標(biāo)準(zhǔn)庫加入了errors.Is、errors.As、errors.Unwrap同時(shí)fmt.Errorf也支持了%w格式化動(dòng)詞。這個(gè)事件的意義不在于它發(fā)明了“錯(cuò)誤包裝”這個(gè)概念而在于它把包裝行為標(biāo)準(zhǔn)化了大家終于有了一個(gè)共同的基礎(chǔ)協(xié)議不同庫之間返回的錯(cuò)誤可以在同一條鏈上做統(tǒng)一判斷。從那時(shí)起Wrap就不再是某個(gè)第三方庫的專利而是每個(gè)Go開發(fā)者都會(huì)遇到的日常選擇。1.3 Wrap成了編碼規(guī)范里最大分歧點(diǎn)標(biāo)準(zhǔn)庫給了“能包裝”的能力但沒有規(guī)定“該不該包裝”。于是Wrap從技術(shù)問題變成了風(fēng)格問題而且很快演變成團(tuán)隊(duì)編碼規(guī)范里最容易被Challenge的分歧點(diǎn)。有人堅(jiān)持“每層都必須Wrap”理由是出問題時(shí)日志里能看到完整的調(diào)用上下文有人堅(jiān)持“能不加就不加”理由是錯(cuò)誤鏈太長(zhǎng)以后根本沒法讀還有人夾在中間看心情包裝。其實(shí)這些爭(zhēng)論背后藏著一個(gè)更本質(zhì)的問題錯(cuò)誤包裝的信息增益原則。每次Wrap都等于給錯(cuò)誤鏈加了一層“說明文字”如果這層說明不能讓下一個(gè)看日志的人更快定位問題那它就不是上下文而是噪音。而要判斷增益是否存在得先把%w和%v的底層機(jī)制徹底搞清楚。2. %w與%v的一字之差決定了錯(cuò)誤鏈的生死2.1 一份代碼看清%w和%v的本質(zhì)差異很多剛接觸Go 1.13的開發(fā)者以為%w只是%v的“新寫法”兩者打出來的日志幾乎一模一樣于是習(xí)慣性選擇%v。這是最常見的誤解?？聪旅孢@段代碼package main import ( errors fmt ) var ErrPermission errors.New(permission denied) func main() { base : ErrPermission wrapped : fmt.Errorf(open config file: %w, base) annotated : fmt.Errorf(open config file: %v, base) fmt.Println(wrapped :, wrapped) fmt.Println(annotated:, annotated) fmt.Println(errors.Is(wrapped, ErrPermission) :, errors.Is(wrapped, ErrPermission)) fmt.Println(errors.Is(annotated, ErrPermission):, errors.Is(annotated, ErrPermission)) }輸出結(jié)果會(huì)讓你意外wrapped : open config file: permission denied annotated: open config file: permission denied errors.Is(wrapped, ErrPermission) : true errors.Is(annotated, ErrPermission): false看到關(guān)鍵了嗎兩個(gè)錯(cuò)誤的展示文本完全一樣但程序化判斷能力天差地別。用%w包裝出來的錯(cuò)誤內(nèi)部實(shí)現(xiàn)了一個(gè)Unwrap() error方法標(biāo)準(zhǔn)庫可以通過這個(gè)鉤子沿著錯(cuò)誤鏈一層層往下找直到找到原始的ErrPermission而%v只是把錯(cuò)誤當(dāng)成普通數(shù)據(jù)澆進(jìn)字符串模板里鏈在那一刻就斷掉了。這就是“一字之差決定了錯(cuò)誤鏈的生死”的含義。日志里看不出區(qū)別但程序里區(qū)別極大errors.Is需要靠鏈去找哨兵錯(cuò)誤errors.As需要靠鏈去提取具體類型沒有%w這兩件事全都做不了。2.2 errors.Is、errors.As、errors.Unwrap三件套的適用邊界理解了%w之后再來梳理標(biāo)準(zhǔn)庫三件套的使用場(chǎng)景就不難了。errors.Is(err, target)沿著錯(cuò)誤鏈逐層比對(duì)判斷當(dāng)前錯(cuò)誤鏈上是否存在某個(gè)哨兵錯(cuò)誤sentinel error常見用例是判斷底層是否返回了sql.ErrNoRows、io.EOF這類可預(yù)期的錯(cuò)誤。errors.As(err, target)沿著錯(cuò)誤鏈查找第一個(gè)類型匹配的錯(cuò)誤并把目標(biāo)指針指向它。常見用例是提取出*json.SyntaxError、*net.DNSError這種結(jié)構(gòu)化錯(cuò)誤拿到內(nèi)部字段比如Offset、Op、Err做精細(xì)化處理。errors.Unwrap(err)只解開當(dāng)前這一層返回內(nèi)層錯(cuò)誤。它一般不出現(xiàn)在業(yè)務(wù)代碼里更多是給工具和調(diào)試用。三者配合的典型寫法是先errors.Is判斷語義層是否命中預(yù)期錯(cuò)誤不命中再用errors.As提取結(jié)構(gòu)信息。例如在網(wǎng)關(guān)代理里resp, err : http.Get(url) if err ! nil { var dnsErr *net.DNSError if errors.As(err, dnsErr) { // 知道是DNS解析失敗可以換個(gè)節(jié)點(diǎn)重試 return retryAnotherNode() } return err }這里如果上游沒有用%w保留*net.DNSError那errors.As永遠(yuǎn)只會(huì)返回false程序就只能對(duì)著字符串做fucking正則匹配——那感覺糟糕透頂。2.3 自定義錯(cuò)誤類型別漏掉Unwrap方法當(dāng)業(yè)務(wù)需要自定義錯(cuò)誤類型時(shí)很多人只記得實(shí)現(xiàn)Error() string方法卻忘了實(shí)現(xiàn)Unwrap() error于是自定義錯(cuò)誤永遠(yuǎn)無法向鏈條深處透?jìng)?。下面這個(gè)例子展示了正確的做法type TimeoutError struct { Op string Cause error } func (e *TimeoutError) Error() string { return fmt.Sprintf(%s: timeout: %v, e.Op, e.Cause) } // 關(guān)鍵讓這個(gè)類型可以被errors.Is/As穿透 func (e *TimeoutError) Unwrap() error { return e.Cause }有了Unwrap方法外層errors.Is(err, io.EOF)就能穿透TimeoutError去判斷內(nèi)層是不是EOFerrors.As也能從鏈上提取出*TimeoutError拿到Op字段。如果漏掉Unwrap自定義錯(cuò)誤就成了一堵墻所有內(nèi)層信息都被關(guān)死鏈從它這兒戛然而止。這里還有一個(gè)常見坑不要把Unwrap誤寫成返回自身。如果你在Unwrap()里返回e本身errors.Is會(huì)陷入無限循環(huán)直到棧溢出。標(biāo)準(zhǔn)庫判斷到“Unwrap返回了自己”時(shí)會(huì)panic但一旦錯(cuò)誤鏈特別長(zhǎng)這種bug排查起來反而更隱蔽。更安全的習(xí)慣是自定義錯(cuò)誤類型里永遠(yuǎn)只有一個(gè)cause字段專門用來保存內(nèi)部的原始錯(cuò)誤。3. 分層架構(gòu)里我堅(jiān)持Wrap的三個(gè)位置穿過機(jī)制層面落到實(shí)際工程里。我負(fù)責(zé)的項(xiàng)目基本都是經(jīng)典的repository / service / handler三層結(jié)構(gòu)經(jīng)過這幾年迭代團(tuán)隊(duì)在錯(cuò)誤處理上形成了一個(gè)共識(shí)repository層不準(zhǔn)亂Wrapservice層必須Wraphandler層做脫敏和狀態(tài)碼轉(zhuǎn)換。下面把每一層的具體規(guī)則拆開講。3.1 repository層盡量不動(dòng)保持原始錯(cuò)誤上岸repository層是離數(shù)據(jù)庫、外部API最近的地方。這里的錯(cuò)誤大多是驅(qū)動(dòng)直接返回的比如sql.ErrNoRows、context.DeadlineExceeded、io.EOF。在我的規(guī)范里repository層拿到底層錯(cuò)誤后不做任何包裝直接返回原始err。原因很簡(jiǎn)單repository是錯(cuò)誤鏈的“起點(diǎn)”信息最完整也最真實(shí)任何提前包裝都會(huì)增加后續(xù)判斷的噪音。func (r *OrderRepo) FindByID(ctx context.Context, id int64) (*Order, error) { var o Order err : r.db.QueryRowContext(ctx, SELECT id, user_id, payload FROM orders WHERE id ?, id, ).Scan(o) if err ! nil { return nil, err // 原始錯(cuò)誤原樣返回 } return o, nil }有人會(huì)質(zhì)疑這里不包一層FindByID failed日志里怎么看得出是哪一步我的回答是這個(gè)上下文不該在這里加。FindByID本身就寫在SQL語句里數(shù)據(jù)庫驅(qū)動(dòng)的錯(cuò)誤文本已經(jīng)足夠說明問題而真正需要“哪個(gè)方法做了什么”的語義上下文應(yīng)該由調(diào)用方service層來補(bǔ)充這樣錯(cuò)誤鏈才不會(huì)有多余的重復(fù)。3.2 service層業(yè)務(wù)上下文在這里統(tǒng)一補(bǔ)充service層是我唯一強(qiáng)制要求Wrap的地方。因?yàn)檫@一層是業(yè)務(wù)的語義邊界你比數(shù)據(jù)庫驅(qū)動(dòng)更清楚這個(gè)錯(cuò)誤代表什么業(yè)務(wù)意圖。比如上面那個(gè)sql.ErrNoRows在repository層就是個(gè)“掃描不到數(shù)據(jù)”的技術(shù)錯(cuò)誤但在service層它是“訂單不存在”這個(gè)業(yè)務(wù)判斷的輸入。所以service的標(biāo)準(zhǔn)寫法是func (s *OrderService) GetOrder(ctx context.Context, id int64) (*OrderDTO, error) { o, err : s.repo.FindByID(ctx, id) if err ! nil { return nil, fmt.Errorf(query order %d: %w, id, err) } // 業(yè)務(wù)組裝... return toDTO(o), nil }這里fmt.Errorf里的“query order %d”信息是新產(chǎn)生的它告訴我們這個(gè)錯(cuò)誤來自哪張訂單、哪個(gè)操作階段。用它替換掉repository層沒有的信息正好符合前文說的“信息增益原則”。而且注意我用的是%w而不是%v這樣上一層還能繼續(xù)用errors.Is判斷sql層的問題。service層的另一個(gè)職責(zé)是保持錯(cuò)誤語義的一致性。比如你想暴露一個(gè)ErrOrderNotFound給handler層判斷不要一言不合就返回一個(gè)新錯(cuò)誤而是應(yīng)該先判斷底層是不是空行再?zèng)Q定要不要轉(zhuǎn)換if errors.Is(err, sql.ErrNoRows) { return nil, fmt.Errorf(order %d: %w, id, ErrOrderNotFound) }這樣handler層只要用errors.Is(err, ErrOrderNotFound)就能做精確處理不需要和數(shù)據(jù)庫驅(qū)動(dòng)耦合。3.3 handler層脫敏和狀態(tài)碼轉(zhuǎn)換的最后一道關(guān)handler層是整個(gè)錯(cuò)誤鏈的終點(diǎn)面向HTTP響應(yīng)或RPC響應(yīng)。這里有兩個(gè)動(dòng)作一是把錯(cuò)誤轉(zhuǎn)換成用戶可讀的信息二是對(duì)外隱藏內(nèi)部細(xì)節(jié)。我通常的做法是“先記錄完整錯(cuò)誤鏈再對(duì)外返回脫敏文本”。func (h *OrderHandler) Get(w http.ResponseWriter, r *http.Request) { id : parseID(r) order, err : h.svc.GetOrder(r.Context(), id) if err ! nil { switch { case errors.Is(err, ErrOrderNotFound): http.Error(w, order not found, http.StatusNotFound) default: slog.Error(get order failed, order_id, id, err, err) http.Error(w, internal error, http.StatusInternalServerError) } return } writeJSON(w, order) }這里要注意handler里一旦把錯(cuò)誤寫進(jìn)日志就不要再把這個(gè)錯(cuò)誤返回給調(diào)用方了也不要向上傳遞否則日志會(huì)出現(xiàn)“get order failed: get order failed”的重復(fù)。錯(cuò)誤在鏈上每層只該“處理”一次要么記錄日志要么繼續(xù)向上傳遞這是我在第4節(jié)要強(qiáng)調(diào)的失控場(chǎng)景之一。4. 包裝泛濫的三重失控套娃、重復(fù)日志與細(xì)節(jié)泄露Wrap是工具不是成就。你把它當(dāng)初戀一樣親錯(cuò)誤鏈就會(huì)變成俄羅斯套娃。以下三種失控我都真實(shí)踩過每次排查都像在剝洋蔥。4.1 套娃式錯(cuò)誤鏈排查時(shí)最怕看到這種日志套娃式錯(cuò)誤鏈的典型特征是每一層都在給同一個(gè)錯(cuò)誤加前綴但這些前綴加起來不產(chǎn)生任何額外信息。比如get order failed: query order from service failed: call repo find failed: find order from db failed: sql: no rows in result set看到這種日志的第一反應(yīng)不是感謝寫代碼的人“考慮周全”而是想問他“你到底要讓我從哪里看起”錯(cuò)誤鏈長(zhǎng)度一旦超過4層中間至少有兩層屬于純儀式性Wrap。而且這種鏈條越長(zhǎng)errors.Is匹配的性能越差雖然單個(gè)錯(cuò)誤鏈沒那么夸張但架不住請(qǐng)求量大日志的可讀性也呈指數(shù)級(jí)下降。我的經(jīng)驗(yàn)是錯(cuò)誤鏈控制在3到5層之間。repository原始錯(cuò)誤是一個(gè)起點(diǎn)service一次的上下文wrap是關(guān)鍵信息handler在記錄時(shí)做一次“收口”語義補(bǔ)充。超過5層你幾乎一定能找到冗余的包裝。4.2 日志與Wrap雙重處理等于錯(cuò)誤被處理了兩次第二個(gè)失控場(chǎng)景是“既記錄又返回”。常見寫法是這樣func (s *OrderService) GetOrder(ctx context.Context, id int64) (*OrderDTO, error) { o, err : s.repo.FindByID(ctx, id) if err ! nil { slog.Error(find order failed, id, id, err, err) return nil, fmt.Errorf(query order %d: %w, id, err) } return toDTO(o), nil }repository層已經(jīng)把這個(gè)錯(cuò)誤寫進(jìn)了日志service層又記錄了一次到了handler層再記錄一次。結(jié)果就是線上排查時(shí)要看三遍同一條錯(cuò)誤Log系統(tǒng)里相同信息被檢索出來三份。社區(qū)里有一句流傳很廣的原則錯(cuò)誤應(yīng)該只被處理一次。要么你在當(dāng)前層記錄日志要么Wrap后向上傳遞但不要既記錄又傳遞更不要每層都記錄。落到實(shí)操上團(tuán)隊(duì)可以約定repository層不記錄錯(cuò)誤日志直接返回service層Wrap且不記錄handler層記錄日志但并不再向上傳遞。這樣一條錯(cuò)誤鏈上日志只會(huì)出現(xiàn)一次完整記錄干凈又精準(zhǔn)。4.3 面向用戶的錯(cuò)誤別讓內(nèi)部細(xì)節(jié)裸奔第三個(gè)失控是“把內(nèi)部細(xì)節(jié)暴露給外部”。有些項(xiàng)目為了省事在handler層直接返回err.Error()當(dāng)作API響應(yīng)數(shù)據(jù)庫驅(qū)動(dòng)的信息就順著接口漏出去了。外部調(diào)用方不僅能看到“dial tcp: lookup db.internal”這種內(nèi)網(wǎng)地址還能通過錯(cuò)誤文本猜測(cè)你的技術(shù)棧、中間件版本甚至能靠報(bào)錯(cuò)內(nèi)容做進(jìn)一步的注入試探。正確的姿勢(shì)是內(nèi)部錯(cuò)誤在service層使用%w保留完整鏈在handler層只輸出一層穩(wěn)定的錯(cuò)誤碼或通用文案。對(duì)外輸出的錯(cuò)誤信息應(yīng)該脫敏對(duì)內(nèi)保留的錯(cuò)誤鏈應(yīng)該盡量完整。這兩者并不矛盾只是作用對(duì)象不同內(nèi)部日志看的是“為什么”外部響應(yīng)看的是“下一步怎么辦”。4.4 哨兵錯(cuò)誤的隱性破壞用了%v斷的不僅是鏈最后一種失控尤其隱蔽項(xiàng)目里定義了哨兵錯(cuò)誤sentinel error后續(xù)卻用%v包裝它。前面代碼已經(jīng)驗(yàn)證過fmt.Errorf(xxx: %v, err)輸出文本沒問題但errors.Is找不到目標(biāo)了。于是業(yè)務(wù)里errors.Is(err, ErrOrderNotFound)永遠(yuǎn)返回false最終被handler當(dāng)成“internal error”返回500客戶端拿到一個(gè)沒頭沒腦的服務(wù)器錯(cuò)誤。這種問題在開發(fā)環(huán)境幾乎測(cè)不出來因?yàn)殚_發(fā)環(huán)境里大部分請(qǐng)求都成功只有到了線上流量大、分支多的時(shí)候某些異常路徑才被觸發(fā)緊接著就被幾百個(gè)“500 internal error”的告警淹沒。如果你在排查這類故障時(shí)發(fā)現(xiàn)“明明錯(cuò)誤信息里寫著order not founderrors.Is卻不命中”不用懷疑八成就是某個(gè)位置的Wrap用了%v。5. 一次訂單查詢故障errors.Is如何在三層鏈里精準(zhǔn)定位理論講多了來一段實(shí)戰(zhàn)復(fù)盤。這是發(fā)生在我負(fù)責(zé)的電商訂單服務(wù)里的真實(shí)案例雖然細(xì)節(jié)做了簡(jiǎn)化但排查鏈路完全還原。5.1 故障現(xiàn)場(chǎng)一個(gè)只留下“internal error”的告警某個(gè)周二下午訂單列表接口的告警突然響起來成功率掉到97%。當(dāng)時(shí)開發(fā)環(huán)境、測(cè)試環(huán)境全都正常只有線上偶發(fā)性失敗?？锤婢罩緃andler層記錄的只有一行l(wèi)oad order list failed: internal error這不是真實(shí)的錯(cuò)誤鏈而是handler把錯(cuò)誤脫敏成了internal error輸出真正的錯(cuò)誤鏈寫在了另一個(gè)字段里。我打開日志詳情一看完整錯(cuò)誤是load order list failed: marshal order 918273 failed: json decode order row failed: unexpected end of JSON input三層鏈每一層都有信息哪張訂單918273、哪個(gè)操作marshal、從哪個(gè)環(huán)節(jié)開始出問題json decode order row。這是當(dāng)初嚴(yán)格按照“repository不包、service包一層、handler脫敏記錄”的規(guī)范留下的成果問題在于——光看文本我還是不知道哪張訂單的數(shù)據(jù)壞了。5.2 順著錯(cuò)誤鏈逐層拆解找到真正的壞環(huán)節(jié)接下來就是用errors.As提取根因類型的時(shí)候。因?yàn)樽罾飳邮莏son decode order row failed: unexpected end of JSON input我懷疑是某個(gè)訂單行的字段非法JSON導(dǎo)致json.Unmarshal解析失敗。于是我在排查用的臨時(shí)調(diào)試端點(diǎn)里加了一段代碼var syntaxErr *json.SyntaxError if errors.As(err, syntaxErr) { log.Println(json syntax error at offset:, syntaxErr.Offset) }結(jié)果還真提取出來了offset精確指向某個(gè)訂單描述字段的斷點(diǎn)。我順著這條線索找下去發(fā)現(xiàn)某個(gè)訂單的payload字段在寫入時(shí)被上游系統(tǒng)截?cái)鄬?dǎo)致JSON內(nèi)容不完整。問題定位到數(shù)據(jù)污染而不是代碼邏輯Bug。之所以能這么高效正是因?yàn)殄e(cuò)誤鏈上沒有斷點(diǎn)repository的原始錯(cuò)誤類型*json.SyntaxError經(jīng)過service和handler兩層Wrap之后仍然保留在鏈里errors.As從最外層一路穿透到最內(nèi)層準(zhǔn)確提取出了細(xì)節(jié)。如果中間任何一處用了%v所有結(jié)構(gòu)化信息都會(huì)變成純文本我就只能寫正則去匹配那個(gè)offset甚至可能被迫重新打開線上數(shù)據(jù)做全量掃描。5.3 如果當(dāng)初用了%v這次的排查會(huì)是什么體驗(yàn)假設(shè)當(dāng)初service層寫的是fmt.Errorf(marshal order %d: %v, id, err)這次事故的排查體驗(yàn)馬上變成另一番光景日志里只能看到一串文本errors.As完全失效想確認(rèn)根因是不是JSON解析錯(cuò)誤要么靠人肉讀日志猜要么把訂單詳情全量拉出來重新Unmarshal一遍驗(yàn)證。在最壞情況下線上一個(gè)偶發(fā)錯(cuò)誤能讓人排查一整天。而正確配置%w之后整個(gè)排查從“猜”變成了“查”錯(cuò)誤鏈上的每一層都有明確信息errors.Is和errors.As把結(jié)構(gòu)化判斷變成程序行為。這個(gè)體驗(yàn)差異就是Wait與Not Wait之間最直白的性價(jià)比對(duì)比。6. 六條Wrap心法寫給我的團(tuán)隊(duì)也寫給你說了這么多最后沉淀幾條我在實(shí)際項(xiàng)目中反復(fù)校驗(yàn)過的原則。它們不是什么高深理論就是寫在團(tuán)隊(duì)Wiki上的約定但確實(shí)讓錯(cuò)誤處理從“個(gè)人品味”變成了“可執(zhí)行的規(guī)范”。6.1 心法一有信息增益才Wrap每次動(dòng)手寫fmt.Errorf(xxx: %w, err)之前先問自己這句話有沒有增加任何一條“前一層不知道的信息”如果有Wrap如果只是給錯(cuò)誤換個(gè)說法停手。信息增益這個(gè)判斷標(biāo)準(zhǔn)能過濾掉八成儀式性包裝。6.2 心法二層級(jí)之間必須Wrap層級(jí)之內(nèi)少Wrap跨層傳遞錯(cuò)誤時(shí)必須Wrap因?yàn)槟悴荒軄G掉調(diào)用方向的上下文在同一層內(nèi)調(diào)用工具函數(shù)時(shí)不要每個(gè)函數(shù)都Wrap否則你會(huì)收獲一條三層起步的套娃鏈。收口原則很簡(jiǎn)單從哪一層進(jìn)了這個(gè)錯(cuò)誤就從哪一層加上第一層業(yè)務(wù)上下文中間的內(nèi)部函數(shù)保持原樣。6.3 心法三需要被程序判斷的錯(cuò)誤必須%w其余按需選擇如果一個(gè)錯(cuò)誤會(huì)被上層用errors.Is判斷比如哨兵錯(cuò)誤或用errors.As提取比如*net.DNSError必須用%w。如果這個(gè)錯(cuò)誤只是合并成日志給人看不再參與程序邏輯判斷%v其實(shí)更安全——因?yàn)槟悴幌Ｍ{(diào)用方和內(nèi)部實(shí)現(xiàn)細(xì)節(jié)產(chǎn)生耦合。6.4 心法四面向用戶的錯(cuò)誤脫敏面向日志的錯(cuò)誤保鏈對(duì)外響應(yīng)永遠(yuǎn)只暴露“用戶能采取行動(dòng)”的錯(cuò)誤對(duì)內(nèi)日志永遠(yuǎn)保留“開發(fā)者能定位根因”的完整鏈。兩者不能顛倒一旦內(nèi)部細(xì)節(jié)漏到外部接口你不只泄露了實(shí)現(xiàn)還把安全隱患交給了別人。6.5 心法五日志和Wrap二選一別兩個(gè)都做記錄日志本身是一種“處理”Wrap繼續(xù)上傳是另一種“處理”。在同一個(gè)層面既記日志又向上Wrap等于把一個(gè)錯(cuò)誤處理了兩遍日志系統(tǒng)里立刻出現(xiàn)重復(fù)信息。要么只記不傳要么只傳不記這個(gè)約定越早定下來后期排查越輕松。6.6 心法六哨兵錯(cuò)誤和自定義錯(cuò)誤類型都是對(duì)外API別輕易改一旦ErrOrderNotFound這種哨兵錯(cuò)誤被定義并廣泛使用它就成為了團(tuán)隊(duì)內(nèi)部模塊之間的契約。改動(dòng)它的文本信息通常還能忍errors.Is是按身份判斷不看字符串但改動(dòng)它的語義范圍或刪掉自定義類型里的字段會(huì)讓所有依賴方一起遭殃。任何對(duì)錯(cuò)誤API的變更都該走和接口變更一樣嚴(yán)格的評(píng)審流程。最后再分享一點(diǎn)個(gè)人感受我見過太多團(tuán)隊(duì)花大把時(shí)間爭(zhēng)論“要不要Wrap”卻沒有花十分鐘把錯(cuò)誤鏈的規(guī)范寫進(jìn)文檔。其實(shí)標(biāo)準(zhǔn)庫errors包設(shè)計(jì)得非常收斂核心就是“保留鏈、可判斷、可提取”這九個(gè)字。真正讓Go錯(cuò)誤處理難用的往往不是語言本身而是我們對(duì)“信息增益”和“層級(jí)邊界”缺乏統(tǒng)一認(rèn)識(shí)。把這兩件事想透了To Wrap or Not to Wrap就不是靈魂拷問只是一道有標(biāo)準(zhǔn)答案的工程選擇題。