错误码如何设计才合理？icode9来为您解答
作者：互联网
导读：对于错误码的设计，不同的开发团队有不同的风格习惯。本文分享阿里文娱技术专家长统对于错误码的看法，希望从错误码使用的不同场景讨论得到一个合理的错误码规约，得到一个面向日志错误码标准和一个面向外部传递的错误码标准。
一 前言
在工作中，接触过不少外部接口，其中包括：支付宝，微信支付，微博开发平台，阿里云等等。每家公司错误码风格都不尽相同，有使用纯数字的，有使用纯英文的，也有使用字母和数字组合的。也接触过很多内部系统，错误码设计也不尽相同。
错误码的输出路径
面向日志输出
-
服务内传递，最终是输出到日志。
-
域内服务间，比如同时大麦电商之间的系统，最终目的是输出到日志。
面向外部传递
-
域内向域外
-
服务端传递到前端
-
OpenAPI 错误码
-
内部不同域之间
错误码使用场景
-
通过错误码配置监控大盘。
-
通过日志进行问题排查，快速定位问题。
-
后端服务之间错误码传递。
-
前端展示的错误提示/OpenAPI。
本文希望从错误码使用的不同场景讨论得到一个合理的错误码规约，得到一个面向日志错误码标准和一个面向外部传递的错误码标准。
PS：本文引用全部引自阿里巴巴《Java 开发手册》，下称《手册》。
二 什么是错误码
错误码要回答的最根本的问题是，谁的错？错在哪？
那么一个错误能表示出谁的错和错在哪里就是一个好的错误码吗？答案显然是否定的，这个标准太基础了。
-
好的错误码必须能够快速知晓错误来源。
-
好的错误码必须易于记忆和对比。
-
好的错误码必须能够脱离文档和系统平台达到线下轻量沟通的目的（这个要求比较高）。
引自《手册》- 异常日志-错误码
错误码的制定原则：快速溯源、简单易记、沟通标准化。
说明：错误码想得过于完美和复杂，就像康熙字典中的生僻字一样，用词似乎精准，但是字典不容易随身携带并且简单易懂。
正例：错误码回答的问题是谁的错？错在哪？
1）错误码必须能够快速知晓错误来源，可快速判断是谁的问题。
2）错误码易于记忆和比对（代码中容易 equals）。
3）错误码能够脱离文档和系统平台达到线下轻量化地自由沟通的目的。
这个原则写在异常日志-错误码这个章节，我认为同样适用在面向用户的错误码。