某些后端不知道是因为太懒还是因为其他原因，对于 json 的数据处理表示很崩溃

首先，命名一踏糊涂，比如某些订单列表数据 A、B、C。

../api/a

{
	"code": 200,
    "msg": "ok",
    "a_list": {
    	...list
    }
}

../api/b

{
	"code": 200,
    "msg": "ok",
    "b_list": {
    	...list
    }
}

../api/c

{
	"code": 200,
    "msg": "ok",
    "c_list": {
    	...list
    }
}

因为这三个 api 接口用的都是相同的页面和布局，就因为这种脑残的 list 命名，前端会为此作出特殊的处理。

再举个例子：不知道某些后端对 json 是不是有什么误会，json 的数组和对象都分不清（在他们眼里，json 的对象和数组都是数组），这不是最恶心的，更恶心的是，同一个 api 接口同一个值，在不同的情况下，给你返回不同的数据类型。比如：

同一个接口:../api/data

某些情况是这样的：

{
	"code": 200,
    "msg": "ok",
    "data": {
    	...list
    }
}

某些情况又是这样的：

```json
{
	"code": 200,
    "msg": "ok",
    "data": []
}

再举个例子，明明不是数组，但是却要用[]来包一层，比如：
已知这个 data 的数据结构永远不是一个数组的。

```json
{
	"code": 200,
    "msg": "ok",
    "data": [{
    	...list
    }]
}

再举个例子，当只有一条数据的时候，是这样的：

{
	"code": 200,
    "msg": "ok",
    "data": {
    	...list
    }
}

当没有数据的时候是这样的

{
	"code": 200,
    "msg": "ok",
    "data": []
}

当有一条以上的时候又是这样的：

{
	"code": 200,
    "msg": "ok",
    "data": [{
    	...list
    }]
}

这些后端不知道是因为懒，还是因为自己的认知有限，每次和这样恶心的接口对接，作为一个前端的人来说，看到这样的接口，就像吃屎一样。和他们沟通不但不认同，还各种推脱说{}就是数组。。。

各位看官，你们觉得这是不是小题大做了？虽然通过各种处理，这些问题都不算啥，但是为何可以通过常识来解决的事，为何不把规则当规则呢？你用 json，就要遵循 json 的规则。而不是这就是 XXX。

各位前端小伙伴们，遇到这样的接口，你是怎么处理的？

exploreXin

2020-02-11 17:29:56 +08:00

都在说后端谁谁谁怎么怎么样，是有人代码不规范，但这不是造成问题的的主要原因，真正原因是团队代码质量体系没跟上，每次代码写完有代码审查制度吗，没有时间代码审查，团队总该有个代码规范约束大伙吧，没有代码规范，开会的时候临时沟通下总该有吧，要是都没有，那代码质量不高也就不奇怪了。写这种水平不高的代码，有的人是懒，不负责任，而有的人是因为上家公司就是这么写的，现在还是这么写，并且现在的公司也没人把这事提出来当做紧要事情处理一下，一个制度完美的团队，应该是就算是 0 基础 0 规范的开发进到团队里面，也可以通过短时间跟上团队的规章制度，按照规范来工作，只是现实中大多都是创业小公司，能活下来就不错了，根本没有时间与精力去搞那些领导眼里“没用”的事情，要什么规范，能赚钱才是王道，两个后端给的东西都兼容不了，给你那么高工资干啥用的，如果遇到这种领导的公司环境，这个基本无解，秉持要么忍要么滚的原则，反正我遇到这种一般都是自己滚的，钱哪里都可以挣，但是技术水平，技术习惯这种个东西随着年月增长，是不可逆的，失去的时间不可能再追回来了，所以与其在不规范团队混日子拿工资，不如去个规范的团队，工资少拿一点也没什么。