后端返回的数据空值时，要不要保持数据类型一致

可能解释的不清楚，就是这个值本来是对象、数组。现在全是 null 了。差不多就是这个意思

我觉得不应该

如果空对象是不允许的，那么后端抛出异常，如果是允许的，前端在 null 的时候显示该显示的东西。

动态语言返回空对象，需要提前定义变量类型，可是不用定义变量类型是我用动态语言最大的原因啊

nullable 本身是一种状态，它跟空值是不一样的。一个是根本没有这东西，另一个是有这东西，但是空的。
最简单的，空字符串和 null，空数组和 null，这都是不同的状态。就看你们的约定里，要不要考虑这种状态了。
我做后端比较多，后端的很多规范里会要求尽量避免使用 null，不然容易炸出来异常。这时候大部分传递的对象或者数组都直接去判断是否为空，而不需要先判断 null 再判断是否为空了。

多数情况下尽可能避免使用 null 应该比较好。但这事情没有定论。

空{}有歧义的吧，分不清空数据还是空值，返回 null 才是合理的，空数组还问题不大，但是返回空{}不返回 null 真是个坑

不指望后端，反正我是自己在前端定义 schema，然后自动做数据清洗。
比如某个字段该是数字，管你是传 null 还是字符串，甚至连父级都不存在，我全处理好然后转为 0 。

关于用户昵称的笑话：

null 、 "" 、 "null"

如果不用 null，你怎么知道用户昵称时被设置为了空，还是就是空的？

空值和 nil 本来就代表两种不同的内容，无论是在代码里，还是数据里

@sujin190 我也同意{}布尔值是 true，在判断上是有问题。感觉都挺懒的，不知道大厂这么做的

@imdong 这种基本类型的为 null 没啥问题的，真的有问题的还是对象。不晓得大厂怎么做的

optional chaining 了解一下，升级下 babel7

根据情况，有些场景是个兼容处理，比如，布尔类型用来表示男女，完全可以支持 null 来表示未设置，也可以强制指定默认值为某个结果，这取舍完全看业务需求，
甚至有的场景下，业务要求在男女不填这三个结果之外填写更多类型，这时候则需要用 int 之类的代替

我一般这样，事先都定义了默认值：
单条记录空就返回｛｝
多条记录空就［］

查询一个列表 返回空数组，查询单个对象返回 null

用 ts 可以在工程化上动动脑筋，比如读取后端接口自动生成调用接口函数，里面写好返回类型，如果不用可以试试"可选链"，后端返回的数据全部用可选链，比如 res?.data?.user?.name 。

最好的还是用 ts，用 ts 他就算给你返回个布尔值都无所谓，反正你这里类型是可控的，出事甩锅给他

后端接口多花 1 天做数据格式统一

前端有 4 种客户端，每个客户端花 1 天时间做数据整理，

你是老板，你选择哪种工期安排？

另外这个事真没啥好打架的，就算后端返回不规范，前端可以在响应拦截器里做手脚，比如把后端返回的 {} 都变成 null，或者把 null 变成 {}

默认值 > null > 空对象
空对象是最惨的，对象里的属性全是 undefined ？在前端类型上还要处理 undefined，如果是 嵌套的多层对象结果，不死得更惨

规范+文档才是真的