一、问题描述
今天在大C的同学找过来给我们提了个技术需求，让我们将接口里返回的字段全不做一下处理，若字段值为 "null" 的时候就不要返回了，他们APP会崩溃。what ? 我想大家立刻马上会冒出这样一个问题之前不是好好的么这么突然就G了。经过一阵交流才发现是技术加方案变化导致的。
二、问题原因
根本原因就是大C要做技术优化，从之前的php代码迁移到 golang，老的php代码在他们那一层做了一个“字端为null就不返回”的过滤。本次技术优化之后不想做这件事。
老的技术方案实现如下：
新的技术方案实现如下：
三、解决方案
业务架构解决规范性讨论：
解决方案从团队角度来说无非就两种，一个就是他们做，另一个就是我们业务方做。我个人剧的他们做更合适。
首先技术优化可以做，但是前提不能影响之前的功能性的东西，不然所有的接入放都要进行适配。对接放愿不愿意改是一回，有没有时间是另一回事。
大C对客户端负责，就一定要保证对客户端的字段的准确性，其实就是三方接口不可信。
大C来做这件事的话其他业务方都不用做重复性的动作了，这样架构也简洁。
若是业务放来做，怎么做，做到什么力度也是个问题，不可能在全局做这样的逻辑处理，除非对大C是一个API。但是显然不可能出现这样的架构设计。举个case：一个接口给大C提供了并且做了这个逻辑判断，但是某一天有个同学给大C提供了个新接口没有人提醒他做这样的逻辑处理，测试的时候各个字段都有，结果上线之后由于业务变化某个字段值没有了，客户端不就G了么。
业务放的解决方案：
若是业务方做这件事的话，有两种方式。
1、按照接口返回对象过滤，使用JsonInclude注解，该注解可作用在字段上也可作用在对象上。
# 引的包
import com.fasterxml.jackson.annotation.JsonInclude;
# 具体注解
@JsonInclude(JsonInclude.Include.NON_NULL)2、按照全局过滤使用配置。
spring:
jackson:
default-property-inclusion: non_null具体采用哪种方式大家视情况而定。大家对于我描述的解决方案的规范性讨论有啥见解，也可以在评论区留言讨论讨论。大家一起进步呀！