错误CODE定义及后端响应体规范

type

status

date

slug

summary

一、全局通用Code定义说明

code值	定义	说明	msg值	备注
0	Success	成功	操作成功。	所有操作成功，查询数据成功，都是返回code=0
-1	Unknown	未知错误	未知错误。	服务代码异常或没有明确的错误
-2	ParameterError	参数错误	参数错误。	ㅤ
-3	PermissionDenied	没有权限	没有权限。	ㅤ
-4	ServiceMaintenance	服务维护	服务器维护，限制写入数据。	ㅤ
-5	EmptyContent	空内容	没有发送内容	ㅤ
-6	NotLogged	没有登录	你的账号由于长时间未登录或出现异常，为了你的账号安全，请重新登录。	ㅤ
-7	FrequentOperations	操作频繁	操作频繁。	ㅤ
-8	ApiExpired	API已过期	API已过期。	ㅤ
-9	RequestNotSupported	请求暂不支持	请求暂不支持。	ㅤ
-10	RequestWrongFormat	请求格式错误	请求格式错误。	ㅤ
-11	ServiceException	服务器异常	服务器异常。	ㅤ

二、错误代码分段

1、Code定义规则说明

修改位数说明：项目变大，分类不够用，把4-6位归到项目小分类，今后所有项目错误代码统一使用本规则；本规则适用于后端、前端、APP等业务接口。原则上定义的错误Code，前后端必须一致，但确定只是前端有的Code，并前后端和产品同步信息，且在后端定义对应的枚举值。

【示例-10010020说明】

-10 0 100 20

【项目】【来源】【功能/模块分类】【流水号】

编号共8位，其中1-2位表示项目，3位表示来源，4-6位表示项目分类，7-8表示小模块的流水号，编号使用0和负数；

第1-2位从10开始编号，3位从0开始编号；4-6位从100开始编号；7-8位从01开始编号；

项目和来源在项目开始之前统一制定，小类各项目根据需要制定；如：项目10表示文档管理，11表示营销系统; 详情见下面列表

第3位表示来源：0表示后端，1表示前端，2表示APP；如果来源后端和前端都有，归为后端0；如果后端和APP都有，归为后端0；如果前端和APP都有，归为前端1；

第4-6位表示功能/模块分类：100-999，尽量是一个和两个项目分类归属在一个文件定义里，方便词条生成维护。定义的ErrorCode按模块文件划分；

第7-8位表示功能/模块分类下的小模块流水号：尽量按照不同业务对象划分段落，按5或10的递增方式；预留以后扩展的。

如：发送邮件验证码的接口：

邮件地址格式为一段：-10010001--10010010；

邮箱发送业务逻辑ErrorCode为一段：-10010020--10010030；

动态验证码为一段：-10010030--10010040；

2、项目编号

编号	项目	示例
10	文档管理	-10010101
11	营销系统	-11010101

3、业务错误代码定义规范

由于项目大类可以从项目编码维护更新，但是到了具体模块下的场景错误，可以使用Apifox工具，在具体接口的文档内容补充上去，方便后续前后端查阅更新。

三、响应体约定

为什么需要统一响应体格式？因为在项目迭代过程中，我们发现前端对后端错误提示文本的处理代码会非常重复，如果要统一封装，势必需求统一返回体的格式，以便于后续在响应拦截钩子函数可以统一处理掉提示，减少前端代码保持操作和提示的交互统一。

后端统一响应体，将ErrorCode以枚举字典统一维护，对于项目错误场景及提示会非常清晰，也易于后续新需求更新做变更，更可以避免杂乱无序的格式带来的前后联调错误问题。

响应体类型定义

成功响应体：

错误响应体

四、错误信息统一拦截处理

对于接口层来说，后端经常定义的结构如下：

bad

good

解决方案

http层axios拿到数据后进行统一处理

到此基本就可以很优雅的写逻辑代码了。不过还有个点可以继续优化。通常情况，后台返回非200错误，只需要$toast提示结果就行，catch代码部分可以省略。类似如下：

多么简洁的代码，但Promise执行reject代码，浏览器会报Uncaught (in promise)错误。这是因为中断了Promise操作但又没有对其进行处理，故由此错误。只需要使用unhandledrejection全局处理即可。