导读：对于错误码的设计，不同的开发团队有不同的风格习惯。本文分享阿里文娱技术专家长统对于错误码的看法，希望从错误码使用的不同场景讨论得到一个合理的错误码规约，得到一个面向日志错误码标准和一个面向外部传递的错误码标准。

一  前言
在工作中，接触过不少外部接口，其中包括：支付宝，微信支付，微博开发平台，阿里云等等。每家公司错误码风格都不尽相同，有使用纯数字的，有使用纯英文的，也有使用字母和数字组合的。也接触过很多内部系统，错误码设计也不尽相同。
错误码的输出路径
面向日志输出

• 服务内传递，最终是输出到日志。

• 域内服务间，比如同时大麦电商之间的系统，最终目的是输出到日志。

面向外部传递

• 域内向域外

• 服务端传递到前端

• OpenAPI 错误码

• 内部不同域之间

错误码使用场景

• 通过错误码配置监控大盘。

• 通过日志进行问题排查，快速定位问题。

• 后端服务之间错误码传递。

• 前端展示的错误提示/OpenAPI。

本文希望从错误码使用的不同场景讨论得到一个合理的错误码规约，得到一个面向日志错误码标准和一个面向外部传递的错误码标准。
PS：本文引用全部引自阿里巴巴《Java 开发手册》，下称《手册》。

二  什么是错误码
错误码要回答的最根本的问题是，谁的错？错在哪？
那么一个错误能表示出谁的错和错在哪里就是一个好的错误码吗？答案显然是否定的，这个标准太基础了。

• 好的错误码必须能够快速知晓错误来源。

• 好的错误码必须易于记忆和对比。

• 好的错误码必须能够脱离文档和系统平台达到线下轻量沟通的目的（这个要求比较高）。

引自《手册》- 异常日志-错误码

错误码的制定原则：快速溯源、简单易记、沟通标准化。
说明：错误码想得过于完美和复杂，就像康熙字典中的生僻字一样，用词似乎精准，但是字典不容易随身携带并且简单易懂。
正例：错误码回答的问题是谁的错？错在哪？
1）错误码必须能够快速知晓错误来源，可快速判断是谁的问题。
2）错误码易于记忆和比对（代码中容易 equals）。
3）错误码能够脱离文档和系统平台达到线下轻量化地自由沟通的目的。 

这个原则写在异常日志-错误码这个章节，我认为同样适用在面向用户的错误码。

标签：代码,语言,系列,编程,严谨,数据,结构,数据结构,抽象 来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。