大家是如何处理异常状态码的？

用户又不盯着控制台

可以分不同类型的 exception

公司统一就行 就怕这边 200 400 500 那边 100001 100002

例如 BizException ApiRuntimeException 等等 根据需要自定义 每种异常处理方式也有所不同

就状态码的 最好跟着 http 状态码走 ！！！

以前会分 http 状态码，业务状态码，现在一律 200 http 状态码，然后业务状态码，最终还是看你自己想用哪种。

HTTP 状态标准还是要遵守的，我在这方面吃过亏。其他的业务状态可以放飞自我。借用老图：

这个看各家的规范了

http status code 不变

请求状态码分客户端错误 10000 - 19999， 服务端错误 20000 - 29999 （也可以改成 40000， 50000）

{error: 10000, message: “ok”}
{error: 20000, message: “服务器错误，或详细描述”}

基本的状态码还是要有的，不如 400，401，403，500，201，204，200，剩下的可以用业务代码补充，如果是单纯的前后台分离，可以一律 200，由业务代码补充

这个没有什么标准，统一规范就行，不过如果是后端提供的服务，有其他应用调用，最好还是用 http 状态码，便于验证服务是否可用

之前尝试过使用 http 状态码，但是前端不太喜欢，就改成了前端喜欢的样子，具体可以看下我的文章。

这个一直都是争议不断的一个话题，我们采用的方案是，尽量的符合 http code，然后使用 json 丰富信息，HTTP 也有标准的解决方案 RFC 7807 可以参照！

{
    "reason":"NOT_FOUND",
    "message":"user not found",
    "errors":[]
}Copy