你们有没有发现 前后端分离/微服务 里结果套结果的情况？

这个是不正常的，既然已经有了统一的错误码字段，没有特殊情况就应该统一处理

挺傻逼的，我点名批评个大厂，某度的金融系统，亲眼看到接口响应就是这么干的，
响应里边包一层别人的响应

HTTP 还有统一的错误码呢 写业务的也有包一层啊

正常，也不正常，同一个公司，不同项目组都能整出来带有各自强烈风格和色彩的 ResponseRsult

@Suaxi 少打一个 e ResponseResult

@pigspy 主要是这个考核，如果传参导致出错，考核的是接口提供方


@zhmouV2 你提到这个，我突然觉得这个包一层的原由是一样的。http 出错导致监控报警太多，所以把业务层和传输层的出错信息要分别开来。

@tf2 把业务的错误和非业务的错误分开来是合理的。但问题是业务的出错基本上都可以套用 4xx ，实在不行也可以 400 再在结果里细分。真要考核那考核 5xx 的错误也就行了。。。

@jhdxr 单说 http 这事，细分的话不如 http 一律 200 然后 json 里细分。

去 http 监控里看业务异常问题是挺鬼畜的。。。。

我理解这种情况是公司已经定义了统一的响应结构，比如
```json
{
"code": 41101,
"error": "xxxx",
"data": null
}
```

但是为了规避统一的错误检查，又在里面包了一层，比如

```json
{
"code": 0,
"error": "ok",
"data": {
"code": "12121",
"msg": "error msg"
}
}
```

这种就是很恶心的做法

上有政策，下有对策

@zhmouV2
http 状态码表达能力太有限了
不如全 200 + 相应内容带自定义状态码，遇到 4xx 5xx 直接按接口报错就完事了

状态码有个好处是在 header 里，access log 之类的直接能体现，但是也可以通过把自定义状态码塞 header 里解决

我们外层只包含三个字段。
{
errorCode:0,
errorMsg:'',
data:null
}

那要是统一错误检查 同时检测处理包的那一层 再包一层呗

code
msg
data

这个理由完全合理