我认为 http 的状态码表示的往往是 http 请求的状态情况，比如 301、302、403、404、500 等等，指的是服务器状态，非业务状态。
我目前对 http 状态码是这样思考的：
1. 对于所有的业务请求，首先如果能响应，则返回 200 码应该是认为请求成功（可能业务出错）
2. 然后在保证了正确响应(200)的情况下，对于业务错误和正确响应是否要统一格式输出的话这个我认为这个是不同团队的处理模式的习惯问题。

我先说下统一格式为{code: xx, msg: xx, data: xx} 这种的：
一般这种的格式，在 API 调用方很清晰，拿到 HTTP 请求的响应后二话不说直接转为一个统一个 ApiResult 结构，然后判断 code，如果非 0，拿 msg 进行提示。这个思路对于大多数前端很直白。

对于另一种情况，成功业务返回 data，异常业务返回 errorCode 的：
那么规则就成了先把结果转 JSON，然后判断是否存在 errorCode 属性，存在认为有错那 msg 提示，否则正常业务。

上述两种模式的第二种存在很明显的问题，就是：要求 data 区域返回值不能有 errorCode。因此对于这种模式一般要区分状态码，比如非 200 表示业务报错，然后辅助判断。我认为楼主说的是这种模式。

这里我觉得两个都行，只是第一个模式思路对大多数人来说很直白而已。第二种模式的话如果 API 调用方的开发环境可控问题也不大。但是！！！


对，我这里要说一个但是！！！微信下开发，那坑爹的安卓版微信浏览器，会默认采用代理发请求，当服务端返回非 200 的响应码时，微信代理抛弃请求，一样的请求从客户端直连二次请求发起！！！
一个案例就是：用户注册，输入用户名服务器判断是否重复注册，此时 ajax 返回非 200 错误比如(500)，然后 response 是错误信息，服务器会二次收到重复的用户注册请求！！！这个坑我相信做个微信开发的人大多数都遇到过。

也是这个坑踩完我重新思考了下状态码的问题，于是就有了第一种方案的结论。