java 协议这个概念_《Java开发手册（泰山版）》定义了统一的错误码方案，是不是太理想化了？...

一个系统要是9999个错误码都不够用。。。那早就该拆分了。

需要升级加前导0即可。

多个服务的调用是链路追踪的概念，可以另外加trace_id，内部使用，不用暴露到外部。

错误码的解释可以由手册文档、配置中心的注释和下文提到的error_message来详细说明。

标准就是标准，具体实现是使用方自己的事。不同的架构和框架，具体实现方式肯定是不一样的。不需要统一的管理错误码的平台，只需要接入一个统一的配置中心，在上面配置就好了。

这个标准没什么大毛病，但是有优化空间，首先引入ABC虽然阅读和识别上有提升，但是只能把错误码定义为字符串类型，作为一个资深c党，看的不是很顺眼，当然是纯数字的整型效率最高，实现最优雅。

(加ABC也可以认为是十六进制的整数，但是内部要加0x转换，说明上也没有提到，那就只能认定是字符串类型了。)

另外统一配置中心之后(后端所有工具和服务加上前端客户端的大前端体系)，code具体对应的error_message就不用在接口上传递了，接口只需要返回一个code。想想google的极简(1个bit表示性别，公共参数缩写极致如_t表示timestamp _u表示user)，特别是对阿里的体量，一点点改进都可以在带宽、存储等等各方面的资源上节约不少，更不用说日积月累。在这些纯工程的环节阿里没有做到最极致的工程思维，才是比较让人失望的。

最后，对c党来说，最完美的错误码就是*inx的设计(mysql等无数开源项目都一脉相承)：

0表示成功或者正常

所有大于0的十进制整数表示错误

具体到业务实现上可以分级，1-99用来定义公共的错误，如：参数校验错误、数据库失去连接、请求超时未响应等，后续各系统按照分段申请保留错误码段，如1000-1999用于用户体系，2000-2999用于商品体系，依次递增。