本文從工作中的具體實踐出發，介紹自己對錯誤碼的一些設計思考。下面將從問題背景、需求分析、設計實踐這三個方面來分別闡述。
拋開具體的業務處理邏輯，這個問題可以抽象為兩種模式：
這種模式，是由前端往後臺傳送請求得到響應，由前端負責封包解包。這裡的報頭和報體具有相同的資料組織格式和邏輯層級，其邏輯一致性由業務服務來保證，具體體現如下：
這種模式，常見於在現有服務中新增乙個中轉服務，專門用來對接第三方服務。由前端負責對接資料的拆包和解包，中轉後台服務只處理網路層的收發邏輯，不關心具體資料內容。
由於第三方服務和中轉服務都存在錯誤可能，因此，前端如何解析響應就需要好好設計。
從使用者的角度來看，期望能夠從請求響應獲取以下三個介面：
該響應是成功還是失敗？
如果失敗，失敗的錯誤碼是多少？
如果失敗，失敗的錯誤描述資訊是什麼？
使用者使用介面1來進行業務分支判斷。一般來說，成功則顯示響應資料，失敗則通過介面2和介面3來提示錯誤資訊。其中，錯誤碼是便於開發定位原因，錯誤資訊是便於終端使用者知曉錯誤情況。
這裡以接入第三方服務返回json格式的響應資料來舉例：一般格式如下：
}
介面2存在的必要性上有分歧。為什麼呢？因為在現有系統中，報文頭和報文體一致模式和不一致模式都存在，且都存在錯誤的情況，在提示使用者時，在是否需要顯示錯誤碼這一點上，產品和開發意見有差異。
struct errorinfo
struct errorinfo m_proxylayer; // 中轉層錯誤資訊
struct errorinfo m_thirdlayer; // 第三方服務層的錯誤資訊
bool bparseflag; // 解析json是否成功
bool bexpectfield; // 期望字段是否存在
個人看法，在該場景下，有兩種妥協方案，在違反單一職責原則的前提下，提供更好的封裝和使用。
方案一：在前端響應時，使用如下資料介面來儲存錯誤資訊：
struct errorinfo
bool isrspright()
int geterrcode()
const string& geterrmsg()const
}
方案二：在中轉層處理，針對第三方服務的指令，提供指令介面卡，將其轉換為前端可統一解包的格式。好處在前端可按照之前封包解包邏輯進行處理，無需關係後端對接型別，按照中轉層提供的介面傳參即可。缺點在於中轉層承擔對接第三方服務的全部工作以及增加指令適配工作，一旦出現異常，所有依賴該中轉層的指令都會失敗
錯誤碼 使用 Go 定義錯誤碼
不管在什麼系統中,定義錯誤碼都是必不可少的.錯誤碼可以幫助定義問題,通常錯誤碼設計為某種模式結構,可以判斷出錯誤的級別,錯誤的模組和具體錯誤資訊.乙個良好結構的錯誤碼有助於簡化問題描述,當前設計的錯誤碼共有五位,結構如下 1 00 01 服務級別 模組 具體錯誤 第一位是服務級別,1 為系統錯誤,2...
錯誤碼總結
200 伺服器成功返回網頁 404 請求網頁不存在 1xx 臨時相應 表示臨時相應並需要請求者繼續執行操作 100 繼續 請求者應當繼續提出請求。伺服器返回此 表示已收到請求的第一部分，正在等待其餘部分 101 切換協議 請求者已要求伺服器切換協議，伺服器已確認並準備切換 2xx 成功 表示成功處理...
HTTP的錯誤碼
錯誤碼 1xx 資訊提示 這些狀態 表示臨時的響應。客戶端在收到常規響應之前，應準備接收乙個或多個1xx響應。100 繼續。101 切換協議。2xx 成功 這類狀態 表明伺服器成功地接受了客戶端請求。200 確定。客戶端請求已成功。201 已建立。202 已接受。203 非權威性資訊。204 無內容...