字典类型的字段没有值时，后端该返回 0 还是 null

小公司，组内没有那么严格，一般跟前端约定，想要什么我就返回什么。。。。不过如果是 int 类型的话我默认也是传数据库的默认值

合理应该是 null ，
- 0: 此字段是必填项，但是有默认值
- Null: 此字段是非填项

返回 0 的话你们要怎么跟值真的为 0 的区分开？

理论上得是 null ，除非你们已经定义了字典值是 0 表示用户未选择。这个情况我觉得在定义上有得商量。

@yannxia 我也觉得是这样，但是现在后端不想处理。。。

没有值的时候，就不该返回这个字段

没有提供值，那就 null 或者不返回此字段

可以返回 0 的情况，只有这个字段本身不包含 0

不想处理，那 0 就 0 呗，大不了后面用-1 表示未填，0 表示 0

@zhangdp
@IvanLi127 会存在为 0 的项，现在就混淆了，本来想前端放拦截器处理，想了想也不行，没法统一判断是不是真的要转成 null ，只能针对字段处理，太繁琐了，维护也麻烦

返回 null ，后端判断下就可以了，返回 0 的做法纯粹是后端偷懒

前端有理

应该是 Integer 类型，不返回最好

`数据库默认也是 0`，这可以转变成数据库字段设计要不要为 null ，有些人喜欢用 null ，有些人喜欢用默认值 0 ，个人感觉按照数据库来就行了，数据库是什么返回就是什么。

有公司规范或者代码规范，就是他说得对
没有就是你对

@nikoxie #9 如果 0 能混淆，你数据库设计时为什么会设计为 not null 且默认值是 0 呢，要改也是从数据库改，仅仅是后端程序不可能判定出是否混淆。

为什么不是不传？

从语义较优的感觉上
不传 > 空串 > 0 = null

平时怎么处理，看团队、看项目规范

你的 api 没有设计 404 吗？
返回 0 和 NULL 都是不对的。

@vishun 我也挺疑惑的，这是我一个前端同事跟其他部门对接时碰到的问题，至少在当前情况下我认为返回 0 是肯定有问题的，默认值也不应该是 0

@matepi create 的时候前端是可以不传的，现在主要是详情接口的后端返回值会是 0 ，他们 dto 里肯定有这个字段的

@loading 可以详细说说吗，请问具体是怎么设计呢