实际开发当中，开发容易遇到哪些问题
- 设计稿中提示语言经常改动
- 大部分小公司没有完整的设计稿
- 大部分开发者英文水平欠佳，变量命名很糟糕，导致拖累开发进度
- 不必要的错误码设计。如：非管理员行使管理员权限，此等为非法操作，不应该单独增加错误提示
我们为什么需要错误码
错误码面向哪些群体
- 用户，用户需要知道具体的错误信息。如：提示登录密码错误
- 前端开发者，开发者需要知道具体的业务错误信息。如：非管理员做管理员操作
- 后端开发者，开发者需要知道具体的业务错误信息，给前端开发者提示
用户对错误码的要求
- 不关心错误码代号
- 反馈信息要准确、言辞要委婉
- 支持多语言（可选项）
- 不同业务操作时，同一错误码提示不同（可选项）
- 结论：
- 后端返回错误码及通用提示信息给前端排查问题，具体提示给用户的信息应由前端开发定义。
开发者对错误码的要求
- 需要根据错误码执行指定操作
- 需要明确的错误提示
- 当某个业务操作失败时，能够迅速定位到业务异常处，并给出合理解释。（非代码异常）
我的错误码设计
重点说明
- 一个正常的客户端应该对某一些操作请求加以限制，当这些操作不满足条件却被发起时，统一返回非法操作错误码，为配合前端开发，将会在开发阶段返回提示具体的错误信息。而不是为每个错误信息编码，以减轻工作量和维护成本。以下示例：
- 非管理员身份发起管理员权限操作
- 非好友关系发起解除好友关系操作
- 发起指定请求缺少参数，参数类型错误
- 请求非法不支持
- 无权限访问
- 服务端不应该过度验证。以下示例：
- 用户设置密码，输入两次新密码，应由前端校验是否一样
- 用户使用旧密码设置新密码，新旧密码一致，应由前端校验是否一样
返回结构
{
"data": {}, # 数据段
"code": "0", # 错误码
"msg": "成功" # 提示（面向前端开发者，上线可关闭，节约流量）
}
错误码设计（缓更）
OPERATION_SUCCESS 0 成功
OPERATION_INVALID 1000 操作非法
OPERATION_FREQUENT 1001 操作频繁
ERROR_UNKNOWN 1100 未知错误
ERROR_SERVER 1101 服务器异常
ERROR_SERVER_OTHER 1102 第三方服务器异常
AUTH_EXPIRE 2000 身份认证信息已失效
