我觉得你同事说的对。400代表 客户端请求的语法错误，服务器无法理解。也可以返回404状态码。
https://www.runoob.com/http/http-status-co... 跟着这个来

赞同你的想法。 前端配合 try 200 catch 其他状态码 ，代码写起来很流畅。

// http statusCode 400  用户相关的错误
{
    code: 400001,
    message: 积分不足
}

// http statusCode 500 服务端相关的错误

实际上，用户基本上不会触发到这条错误，类似你举的例子，积分不足兑换奖品，其实前端都已经拦截了，根本不会发请求到后端吧，这样处理主要是用来防小人的。

这是一个世纪难题。。。

有两层：

• 服务层
• 业务层

服务层无需控制，默认即可，业务层才是需要控制状态码

一般最好还是 按照http返回值200 然后response里加一个code 来表示 错误code
因为 毕竟这个请求是成功的 只是因为一些业务逻辑的影响 导致操作不成功 所以就用业务的code来处理

我做法的出处是来自 Restful API 的约定，因此返回了不同的状态码，但是实际使用就有点迷惑了 :joy:

我这边是都返回200，根据code来判断，前端也不用判断状态码，协商好就行。

我支持200 你可以看到微信提供的API也是200 带 code 或者 message 等一些识别参数 毕竟HTTP的状态码过于局限，很难去描述清具体的错误详情 而且400或者其他状态码还增加了工作量

支持 200 ,这样更合理

200+code+message

两种写法,感觉统一了就好,用哪种前端人士说无所谓 :joy:

服务器正常返回就是200，被动报错或者主动报错就是自定义状态码code

我觉得统一一下就行了，，，

首先 500 这个应该没大多疑问，，

疑问在于，，，

• 业务错误，比如积分不够
• 传参错误，比如积分兑换奖励，没有传奖励 ID，这种又不属于表单验证，不能用 422

对于这两种，要么统一用 400，要么统一用 200 吧，，，不然前端还要在两个地方处理错误，，，

我个人倾向于用 400，这样 200 响应里，不用多包一层，，，

状态码的话，前端统一收集处理，一套代码用到所有接口

code的话，特殊业务单独返回处理

这样的话既有惯例又有特例，多棒！

http status code ，是判断 HTTP 请求成功与否的，跟你业务逻辑上成功与否没半毛钱关系，为何要混用？
参考微信支付返回结果，return_code SUCCESS/FAIL 此字段是接口通信情况标识，非交易成功与否的标识
这个 return_code 其实跟 http status code 类似，就是告诉你这次通信成功与否，是通信层面，不是业务方面。
微信支付返回结果里边，当return_code为SUCCESS的时候，result_code 才是业务结果。
我是赞同你同事的做法，不要把国际通用的 http status code 私有化而破坏了它本身的用途。