为什么后端经常会出现不按接口定义的类型返回值呢

我有个疑问，为什么后端经常会出现不按接口定义的类型返回值呢？

例如文档上写着：
```ts
{
    id: number;
    data: string[];
}
```
返回的时候却返回：
```ts
{
    id: "1000",
    data: null,
}
```
为什么后端不做处理呢？换过几家公司，见过好几个后端这样的了。一般来说，定义了`number`就返回`number`，定义了数组至少返回空数组`[]`吧？

第一个 ID 不应该，要他统一一下。
第二个为空用 null 我倒是见的不少，不单数组，整形、字符串为空都返回 null ，有些系统是这样的，这个做法正常不正常有待商榷

id：number ，有时候是需要转为 string 下发，但也仅限大于 48 位的整形。

我们后端就是这样的，跟他反馈，丫还说让前端对每一个字段判空。。。

呃，我自己做的 data 为空是返回 null 的。不过有文档的话还是以文档为准

可能 data 可能是查询数据的结果，查询到了是数组，查不到是 null 。

因为很多语言的引用类型都是 nullable 的，在业务上如果查不到对应的内容，可以返回 null ，可以返回一个 default(T)，也可以用 code 来区分是否有数据，a matter of taste ；至于 int 和 str 的问题，老生常谈，有时候是从 Redis 里拿出来就直接丢出去了，说明 Deserialization Serialization 做的不好，或者素养不行

```
{
    id: long;
    data: string[]?;
}
```
因为后端定义的是长整型 id 和 nullable data.

1 ，后端自作多情将长整型统一序列化成了 string ，以为是在帮前端擦屁股(其实前端完全能做到不丢失精度)，结果没擦干净(Model 转文档时没改数据类型)
2 ，接口转文档没定义完整 Schema ，导致为标注参数是否 nullable

id 是 number 类型而返回的是字符串的原因大概率是因为后端使用的是 long ，js 处理后端返回的 id 时会丢精度。所以后端对于 long 类型在转为 json 的时候会转为 string 返回。

后端是 PHP? number 和 string 混用很正常