# 错误码设计 * * * * * ### 错误码列表 ![](https://box.kancloud.cn/732f9a53f296d22fd82a51ce892c2511_1917x839.png) 此处咱们来详细讲解下系统的错误码设计。 从图中可以看出 OneBase 的错误码规范。 code 第1位(错误提示级别),第2-3位(错误模块),第4-7位(错误代码) 咱们不管是查询还是写入或更新操作,所有的操作成功都统一返回 0,代表操作成功。 除了 0 以外,其他的错误码 全都是 7 位数。 7位数 中的 第一位 代表了 错误级别, 1 为业务逻辑级别的错误, 2 为系统级别的错误。 共 9 种错误级别的位置,剩下的开发者有需要可自行扩展。 第二位和第三位 为系统的错误模块定位号码,例如咱们可以看到 签名有 00的 后面 还有 01的, 作者把接口验证相关的错误码归为了 00 模块,这样 以后一看到错误码就知道是哪里有问题啦,用户相关的验证 为 01 模块,后面还有 90多个模块位置 留着给研发者扩展哦。 最后一组是 第四位到第七位,代表详细的错误位置定位号码,通过这 七位 号码 咱们开发者可以直接定位错误原因,然后迅速找到解决方案。 下面咱们来看看 error 目录中的错误码类是啥样的。 ![](https://box.kancloud.cn/3b908ffbb3705e19248755487dce3a20_1000x620.png) ![](https://box.kancloud.cn/0c382c949b4ae8bd6851ef502b889712_929x614.png) 看到了吧,咱们每个模块对应一个错误码类文件,CodeBase 为基础模块 保存着访问 api 相关的错误信息,Common 为通用的错误模块,比如 登录注册 此类整系统通用的错误码。 类中都是以静态属性方式存储数据,属性名称命名尽量易懂,一看就知道是什么意思才行,属性里面包含错误码和错误描述。 ![](https://box.kancloud.cn/895483442a98c43249edb712516084ef_994x403.png) 在 api 模块的业务逻辑研发中,直接以 return CommonError::$passwordError; 此类方式调用静态属性返回,无需关注上游是怎么处理的,只需要专注业务逻辑研发即可。