Springboot项目错误码的设计与实现.docx

? ? Springboot项目错误码的设计与实现 ? ? HTTP状态码和我们平时的错误码不同，状态码太少了，无法满足我们业务中的需求。然而，所有请求都返回200，然后数据体里包含错误码的方式，又抛弃了HTTP状态码，抛弃了普遍共识。本来应该遵照HTTP协议的约定，根据HTTP状态码设计返回体。然而，很多电信营业商会拦截非200响应。采用 {error} or {result} 的形式：程序遇到错误时，前端返回错误码和错误信息。正常时，直接返回期望的结果。这种方法是作死，增加了复杂性! 所以推荐的做法是采用{error，result} 的形式：正常响应和错误都放在body体里 一、返回格式 正常访问服务器时，返回200的HTTP状态码，然后内部描述正常或错误信息 { errcode:A2001, errmsg:access_token expired, data:{ userid: zhangsan, name: 张三, department: [1, 2], open_userid: xxxxxx } } 二、错误码的设计 好的错误码解决的基本问题是“谁的错？”。更高的要求是（1）易于记忆和比对（Equals）。（2）脱离文档和系统平台达到线下轻量化地自由沟通的目的。 （一）设计原则 根据《阿里巴巴开发手册》建议，错误码的制定需 快速溯源，沟通标准化 不体现版本号和错误等级 全部正常时，返回00000 为字符串类型，共5位（产生来源，四位数字编号） 不得与公司业务和组织架构挂钩，应该自增数字 因为国际化i18n，不要用枚举定义错误码 不能直接输出给用户作为提示信息使用，不要替代错误信息（errorMessage） 错误码可分为一二三级宏观错误，跟HTTP状态码没有关系 1.为什么不能用纯数字错误码？ 因为数字错误码，不便于感性记忆和分类，不容易记住。 在日志中无法确定某串数字是否是错误码，还是某个数值。 2.为什么不能用纯字母错误码？ 纯字母错误码不便于排序，用英语不能准确描述错误。 3.错误码的输出路径有哪些？ 分为两类： 3.1面向日志输出 服务或域内传递，最终是输出到日志。 3.2面向外部传递（常用） 域内向域外 服务端传递到前端 OpenAPI 错误码 内部不同域之间 4.输出到日志和输出到外部的错误码有什么区别？ 按照《手册》的建议设计出的面向日志的错误码定义共十三位（十位有意义，三位连接符），并且应该具有如下分类： 应用标识，表示错误属于哪个应用，三位数字。 功能域标识，表示错误属于应用中的哪个功能模块，三位数字。 错误类型，表示错误属于那种类型，一位字母。 错误编码，错误类型下的具体错误，三位数字。 《手册》还有一条是规定错误码应该如何定义： 错误码为字符串类型，共 5 位，分成两个部分：错误产生来源+四位数字编号。 五位错误码的好处是易记，但是对于面向日志的错误码场景利用错误码制作需要分类的业务监控大盘将变得比较困难，比如统计应用 A 的功能 B 的错误出现次数。 同样在系统间传递这个类型的错误码非常有可能发生错误码冲突。 当然对于分为四段的错误码同样尤其不好的一面，应用标识和功能域标识需要有专人去管理或者开发一个错误码管理工具，否则时间一长很容易产生定义的混乱形成破窗。 因此，五位错误码适合传递到外部。 5.面向外部传递的错误码如何分工协作？ 域外系统通过错误码进行后续的动作，或是中断操作，或是记录日志继续执行。 前端通过错误码，给出用户准确的错误提示或者忽略错误进行重试。 （二）实现方式 错误码可以和国际化结合起来实现 在springboot项目的resources目录中创建i18n文件夹，在文件夹下创建perties等三个国际化配置文件，IDEA会自动创建Resource Bundle并绑定这三个国际化配置文件。 perties和messages_zh_CN.properties文件配置参考如下： 00000=请求成功 A0001=用户端出错 A0002=参数 {0} 缺失 A0003=参数 {0} 长度不合法 A0004=参数 {0} 格式不正确 A0005=参数 {0} 类型不合法 A0006=参数 {0} 状态已过期 A0007=参数 {0} 非法 A0008= {0} 不存在 A0009= {0} 已存在 A0010= {0} 重复 A0011= {0} 不允许被删除 A0101=用户权限不足 A0102=用户操作频繁 B0001=当前系统出错 B0101=系统正忙，请稍后再试 C0001=第三方服务出错 messages_en_US.properties文件配置参考如下： 000