某些后端不知道是因为太还是因为其他原因，对于 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。

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