错误码设计以及 Django 的异常统一处理
笔者目前使用 Django 从事 SaaS 开发，同时开发和维护多个 SaaS 应用。在很多 SaaS 应用中都约定了错误码，有的用于处理登录态，有的用于标记业务逻辑状态。对于这种项目共性很强的特征，花时间学习和研究是非常有必要的。本篇主要讨论了错误码的用途、如何设计错误码、使用 Django 中间件如何实现异常的处理错误码的返回。
1. 错误码的用途
错误码是与错误信息关联的一组数字或字母，用于约定错误状态。在 Web 应用中，一次接口的访问，涉及反向代理的转发、业务逻辑的处理、数据库的访问、模板的渲染、中间件的处理等环节，难免会出现各种各样的错误。同时，系统越复杂，访问的链路越长，模块越多，出错的可能性越高。既然错误无法避免，那么就需要反馈错误信息。返回错误信息，一方面是为了在应用系统开发阶段，方便调试，添加相应的逻辑处理，提示用户；另一方面是应用系统运行时，可能会有潜在的异常风险，错误码能辅助定位和修复问题。HTTP 状态码是最常见的，通过提前协商处理服务状态的约定编码。HTTP 状态码通常由三个数字组成，第一个数字定义了响应的类别，且只有五种可能值。| 1xx | 100-101 | 指示信息–表示请求已接收，继续处理 |
| 2xx | 200-206 | 成功–表示请求已被成功接收、理解、接受 |
| 3xx | 300-305 | 重定向–信息不完整需要进一步补充 |
| 4xx | 400-415 | 客户端错误–请求有语法错误或请求无法实现 |
| 5xx | 500-505 | 服务器端错误–服务器未能实现合法的请求 |
| 0 | 成功 | 调用成功 |
| 401< | HTTP请求参数不符合要求 | HTTP请求参数不符合要求 |
| 503 | 调用额度已超出限制 | 调用额度已超出限制 |
| 504 | 服务故障 | 服务故障 |
| 4000 | 请求参数非法 | 缺少必要参数，或者参数值格式不正确，具体 |
| 6000 | 服务器内部错误 | 服务器内部出现错误，请稍后重试或者联系客服人员帮忙解决。 |
| 服务级错误（1为系统级错误） | 服务模块代码 | 具体错误代码 |
| 10014 | 服务模Insufficient app permissions | 应用的接口访问权限受限 |
| 20603 | List does not exists | 列表不存在 |
| 20701 | Repeated tag text | 不能提交相同的收藏标签 |
| 0 | 成功 | Success |
| 1 | 未知错误 | Unknown error |
| 2 | 服务暂不可用 | Service temporarily unavailable |
| 100 | 请求参数无效 | Invalid parameter |
| 101 | api key无效 | Invalid API key |
| 102 | session key无效 | Session key invalid or no longer valid |
| 103 | call_id参数无效 | Invalid/Used call id parameter |
| 40001 | invalid credential | 不合法的调用凭证 |
| 40008 | invalid message type | 不合法的message_type |
| 40016 | invalid button size | 不合法的菜单按钮个数 |
| NOAUTH | 商户无此接口权限 | 商户未开通此接口权限 |
| ORDERPAID | 商户订单已支付，无需重复操作 | 商户订单已支付，无需更多操作 |
| SYSTEMERROR | 系统错误 | 系统超时 |
| 2 | 05 | 02 |
| 服务级错误（1为系统级错误） | 服务模块代码 | 具体错误代码 |
| 2 | 050 | 0200 |
