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

可能解释的不清楚，就是这个值本来是对象、数组。现在全是 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，如果是 嵌套的多层对象结果，不死得更惨

规范+文档才是真的

空对象和 null 完全不同的意思，我倾向于 null

空对象到处是坑，如果返回给前端的接口数据为空返回的空对象，假如后面有一个新服务也调用了这个接口，那么 rest 请求成功了，得到一个空对象，这个方法倒是不报 npe 了，一用这个对象的某个值就报 npe，而且一般都是在 rest 接口调用的 service 做为空判断，谁还管你里面的值是 null，无形之中增加了排错的逻辑

现在负责的系统里面，有些接口返 null，有些接口返空对象，没办法去搞，直接全部不可信，然后就导致代码里面到处是判空的代码

null 和{}意义不同，约定好就行

@holystrike 客户端开发要是无条件相信后端返回的值，那迟早会出现崩溃，这种客户端要不得。

@Sapp 也不是打架，一般公司后端还是比前端腿出的，就是想问问大家这么做的

我以前公司也是经常因为这个吵,但是基本上还是返回 null.
我感觉我没理由去给你返回一个空对象,
你要是要求我给你一个空对象,为什么不要求 mysql 返回给我一个空对象
要是有排空的逻辑,就另外处理了...
不过当时是小公司,一共二十几个人,都是看心情....

null
[]
0
''
false

@imdong #9 不允许设置空昵称就行了

其实我是想支持 null，但是根据我以往对接 iOS 的经验，null 在 iOS 那边处理有点麻烦，后面就统一用""代替了。

我也不是做 iOS 的，但是经过我搜索 iOS 对 null 的处理，确实有点麻烦。

个人倾向于使用 null, 多出一个确定的空值可以表达更多的状态, 而且很多时候'没有值'和'有值但为空', 在逻辑里完全是两种含义

Object 这个场景下 null 是正确的。
但 Array 就不一样了，我对接的大部分后端，列表查询为空时也返回 null，其实应该是[]。

赞同#32 楼，对象里面有 null，很合理。 空数组如果用 null 就扯几把蛋

null 和空数据本来就不是一回事。举几个例子：
未设置项：null
某项设置为空：""
按某条件搜索无结果：[]

如果前端 /客户端说 xx 不好实现让返回 yy，建议一律当场开除。

@xiangyuecn
早年还见过 true/false 返回 1/null 的。（

所以还是要定好编码规范啊。不然就吵没完了。

null 和 0 不一样的含义

数字默认 0，字符串默认"",布尔默认 false,数组默认[]，对象默认 null，
前面几个应该没太多异议，空对象不建议{}，不然使用每个属性的时候都得判空