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

[erwin985211]

最近前后端干的厉害，后端返回数据的时候，有些值是空往往就返回 null，这些往往是引用类型类型。

前端表示对象就算是空那就返回一个空对象，后端表示前端都不做数值判断的吗，现在是引入 lodash 或者自己写一个公用的判断方法。但依然不爽，后端应该不应该保持数据类型一致呢

[hoyixi]

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

[Mystery0]

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

[Mystery0]

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

[Maboroshii]

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

[icyalala]

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

[erwin985211]

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

[wr516516]

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

[huijiewei]

null
[]
0
''
false

[Leonard]

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

[ChoateYao]

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

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

[hxtheone]

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

[chairuosen]

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

[xiangyuecn]

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

[Elethom]

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

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

[Elethom]

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

[hhyygg]

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

[hbhswj]

null 和 0 不一样的含义

[mshadow]

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