@justfindu 因为前端对数据的类型是有“预期”的（按照约定）。比如说正常来说数组都是用来遍历的，但是后台就返回了个 null，导致遍历失败报错。如果我按照“预期”把它变成一个 []，那不就解决了。团队开发者一多，沟通成本很高，反正我提过很多次了，根本没人鸟我。

@wotemelon 这个有这么点意思，好像是我想要的东西。谢谢！

炫富贴

@Mutoo 这种实际上就是逐个字段判断了。而且这个 defalt 有局限性，处理的只是 key 不存在的情况。万一存在而且是 null，那还是会有问题。还得再加判断。麻烦得很。

@jzhang 看了一圈文档，貌似没有发现对缺失值的处理办法？

@isbase 默认值只能解决很小一部分的问题。通常数据都会有深层次的结构。

@kaneg 同上。

@will0404 组织已经决定了，这个锅就 tm 前端来背。

@zjsxwc 你说的这种“网关”其实不切实际。这样一来架构会变得极其脆弱。

@maemual 主要是用来显示的这一块，不往回发。一报错测试马上就找到前端来了，各种背锅。

@Torpedo 你这个办法看起来不错，我这边也是 RN，明天试一下。谢谢。

关注的人自然会知道如何继续关注。不关注的人你做一百个这种东西也没用。从根本上“失去关注”的问题制造者不是媒体，而是人。

@muziyue 打得了现任打不了下一任，自己不做处理总会有被坑的一天。

@orancho 这个好像是新的数据交换结构，新项目可以考虑，可是现有的基于 JSON 的项目怎么搞？

@264768502 好像不是我想要的东西。

https://blog.wxsm.space/feed.xml

尝试了一下，添加以上 url 失败了。失败第一次以后，继续提交此地址提示“已存在”。

其实感觉没什么必要。这样一改感觉信息流变得混乱了。

弹广告用的

实话说当不当码农跟学历没太大关系。

“ 1 代表完全不同意、2 代表较不同意、3 代表不同意、4 代表不确定、5 代表有一点同意、6 代表较同意、7 代表完全同意”

有偿的也没这么麻烦的选项吧？

支持。建议改成 repo +1

1. 公司名都没有。“大数据行业头部公司”不知道是个什么鬼，所以你到底是叫“大数据行业头部公司”还是“头部公司”？不过二者都搜不出什么东西来。
2. 公司后缀的邮箱也没有。“行业领先”的公司招聘留个人电话的，是第一次见。
3. 具体地址没有。
4. 薪资待遇没有。

综上，我很怀疑是个传销组织，或者骗子公司。