阿里開發手冊泰山版學習筆記十一、異常日誌-錯誤碼

1. 【強制】錯誤碼的制定原則：快速溯源、簡單易記、溝通標準化。
   說明： 錯誤碼想得過於完美和複雜，就像康熙字典中的生僻字一樣，用詞似乎精準，但是字典不容易隨身攜帶並且簡單易懂。
   正例：錯誤碼回答的問題是誰的錯？錯在哪？
   1）錯誤碼必須能夠快速知曉錯誤來源，可快速判斷是誰的問
   題。
   2）錯誤碼易於記憶和比對（代碼中容易 equals）。
   3）錯誤碼能夠脫離文檔和系統平臺達到線下輕量化地自由溝通的目的。

2. 【強制】錯誤碼不體現版本號和錯誤等級信息。
   說明：錯誤碼以不斷追加的方式進行兼容。錯誤等級由日誌和錯誤碼本身的釋義來決定。

3. 【強制】全部正常，但不得不填充錯誤碼時返回五個零00000。

4. 【強制】錯誤碼爲字符串類型，共 5 位，分成兩個部分：錯誤產生來源+四位數字編號。
   說明：錯誤產生來源分爲 A/B/C，A 表示錯誤來源於用戶，比如參數錯誤，用戶安裝版本過低，用戶支付超時等問題；B 表示錯誤來源於當前系統，往往是業務邏輯出錯，或程序健壯性差等問題；C 表示錯誤來源於第三方服務，比如 CDN 服務出錯，消息投遞超時等問題；四位數字編號從 0001 到 9999，大類之間的步長間距預留 100。

5. 【強制】編號不與公司業務架構，更不與組織架構掛鉤，一切與平臺先到先申請的原則進行，審批生效，編號即被永久固定。

6. 【強制】錯誤碼使用者避免隨意定義新的錯誤碼。
   說明：儘可能在原有錯誤碼附表中找到語義相同或者相近的錯誤碼在代碼中使用即可。

7. 【強制】錯誤碼不能直接輸出給用戶作爲提示信息使用。
   說明：堆棧（stack_trace）、錯誤信息(error_message)、錯誤碼（error_code）、提示信息（user_tip）是一個有效關聯並互相轉義的和諧整體，但是請勿互相越俎代庖。

8. 【推薦】錯誤碼之外的業務獨特信息由 error_message 來承載，而不是讓錯誤碼本身涵蓋過多具體業務屬性。

9. 【推薦】在獲取第三方服務錯誤碼時，向上拋出允許本系統轉義，由 C 轉爲 B，並且在錯誤信息上帶上原有的第三方錯誤碼。

10. 【參考】錯誤碼分爲一級宏觀錯誤碼、二級宏觀錯誤碼、三級宏觀錯誤碼。
    說明：在無法更加具體確定的錯誤場景中，可以直接使用一級宏觀錯誤碼，分別是：A0001（用戶端錯誤）、B0001（系統執行出錯）、C0001（調用第三方服務出錯）。
    正例：調用第三方服務出錯是一級，中間件錯誤是二級，消息服務出錯是三級。

11. 【參考】錯誤碼的後三位編號與 HTTP 狀態碼沒有任何關係。

12. 【參考】錯誤碼儘量有利於不同文化背景的開發者進行交流與代碼協作。
    說明：英文單詞形式的錯誤碼不利於非英語母語國家（如阿拉伯語、希伯來語、俄羅斯語等）之間的開發者互相協作。

13. 【參考】錯誤碼即人性，感性認知+口口相傳，使用純數字來進行錯誤碼編排不利於感性記憶和分類。
    說明：數字是一個整體，每位數字的地位和含義是相同的。
    反例：一個五位數字 12345，第 1 位是錯誤等級，第 2 位是錯誤來源，345 是編號，人的大腦不會主動地分辨每位數字的不同含義。