返回碼規范

最好在一套系統中，甚至一個團隊，一個公司中都遵循一套返回狀態碼規則，并提前做好規劃，比如：
0001 ~ 1999 ，2000 ~ 2999，4000 ~ 4999

這些碼段可以按：業務類型，按功類型，按架構層面提前規劃好，比如x~y是網絡段的，哪段用于錯誤碼，哪段用于成功碼，感覺這樣從架構層面上來分比較清晰，一下子就知道是成功還是失敗了，然后根據其它位上的數還可以識別出業務層上面的特征，感覺這幾種規劃組合起來有最好的效果，給出碼段。這樣整體規劃就能達到統一了。
ABCD四位
A：？
B：？
C：？
D：？

比較成熟<愛尬聊_生活百科>的系統，比如微信，一些軟件，網站在各種情況，或者各種出錯時都會有一個返回狀態碼，我知道這個狀態碼每個業務都有，一個系統中業務那么多，肯定有一個好的返回碼設計規范的。

想請問一下大家一般這種規范怎么設計呢，遵循什么標準呢，哪兒可以找到參考的資料呢？
（我記得以前哪兒看到過美團外賣的接口返回碼設計標準，現在忘記了找不到了）

---

360U3138636770 11小時前

個人認為，大型應用體系中的錯誤碼應該是少數的，就像RESTful設計HTTP接口那樣，常用的錯誤碼不到10個，其詳細的錯誤內容直接以錯誤信息的方式顯示，不是使用錯誤碼來定義。設計詳細的錯誤碼也是為了判斷錯誤的，與其遇見錯誤時根據錯誤碼再去查錯誤碼表找到錯誤信息，不如直接傳錯誤信息。

---

王昭源_2020 11小時前

不建議使用錯誤碼機制。你所看到的微信、微博等的接口，它們都是對外提供的，數量有限，制定錯誤碼非常容易。但是對于內部系統，特別是龐大的系統，制定錯誤碼純屬浪費時間。而且，錯誤碼越詳細，系統之間的耦合度就越高。試想某一個模塊增加一個錯誤碼，會影響整個系統中程序對錯誤的判斷。

---

王昭源_2020 11小時前

是的，有明回答的也是我的看法。如果一定要制定錯誤碼的話你要考慮的是怎么寫文檔和如何管理錯誤碼，錯誤碼本身不重要。即使你只有10條錯誤碼，開發者也不會都記住！所以考慮錯誤碼規律性、簡潔性、可讀性根本不重要。你想想HTTP的錯誤碼就知道了，除了200，301，403，404，500你還記得啥？

---