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

• 主 資深大佬 : erwin985211

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

• 資深大佬 : misaka19000

  我觉得不应该

• 資深大佬 : lychs1998

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

• 資深大佬 : draguo

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

• 資深大佬 : Mithril

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

• 資深大佬 : cmdOptionKana

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

• 資深大佬 : sujin190

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

• 資深大佬 : woodensail

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

• 資深大佬 : imdong

  关于用户昵称的笑话：

  null 、 “” 、 “null”

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

• 資深大佬 : baiyi

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

• 主 資深大佬 : erwin985211

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

• 主 資深大佬 : erwin985211

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

• 資深大佬 : tjsdtc

  optional chaining 了解一下，升级下 babel7

• 資深大佬 : opengps

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

• 資深大佬 : xiaochong0302

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

• 資深大佬 : Sapp

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

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

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

• 資深大佬 : holystrike

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

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

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

• 資深大佬 : Sapp

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

• 資深大佬 : otakustay

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

• 資深大佬 : raaaaaar

  规范+文档才是真的

• 資深大佬 : 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，
  前面几个应该没太多异议，空对象不建议{}，不然使用每个属性的时候都得判空