Fastjson vs Jackson, Jackson配置Null时返回空值

Posted 2023-03-16

参考技术A 最近在使用apifox进行自动化接口测试时，发现当String, Integer等返回Null时，无法通过默认的返回数据结构校验。

于是开始寻找响应解决方案，满足以下需求：

基于Fastjson的解决方案相对比较简单，但是Spring默认的Json处理框架是Jackson，如果替换为Fastjson，会导入引入一些额外问题，遇到过的比如有wx的反方授权回调接口参数解析错误，返回的字段外面多套了一层“”。

另外参考了 maven repository 上 ，jackson的使用还是大大大于fastjson，且最近fastjson又有爆出安全漏洞，最终还是决定改回Jackson，基于Jackson来解决Null的返回值问题。

试了几种方案，走了一些弯路，这里直接上最终方案吧。

自定义JacksonConfig类，设置返回所有字段，实现自定义BeanSerializerModifier，注入到SerializerFactory中，判断字段类型如果为列表、字符、数字、Boolean，则指定自定义的Null序列化实现

同时，由于Jackson针对日志时间处理的默认处理格式为yyyy-MM-ddTHH:mm:ss，在配置类中改为yyyy-MM-dd HH:mm:ss格式。

如果对你有帮助，请点赞

Jackson替换fastjson的几个坑

参考技术A 最近fastjson漏洞频出，于是公司要求将所有的应用fastjson引用都换成jackson。这期间改造了大量应用，踩出来的坑珠峰倒进去估计也填不满。

首先是fastjson本身的一些小问题，由于其封装度很高，写起来比较偷懒。老应用中很多同事的偷懒写法，改的我几乎吐血。例如JSONArray，看似是对JSON对象的数组的封装，实际上什么都能放，就是一个List<Object>，众所周知泛型写Object是最偷懒的写法，对后来者实在是太不友好了。。。遇到JSONArray的使用，改造时只能先写成List<Object>，再小心翼翼的根据上下文，转换出具体类型。

说到类型转换，就不得不提JSONObject特别亲民的一系列getString()，getBigDecimal接口，写起来那叫一个方便。老应用中RESTFul接口的RequestBody也不定义Bean，直接JSONObject接着就完事，想用String就getString，当JSONObject被替换成Map的时候，再转String就不能直接用类型转换了，因为getString是兼容了其他不是String的类型的，当然也不能用String.valueOf方法，因为null类型的处理会有偏差。所以遇到这种情况，只能乖乖的自己写一个类型转换的工具类。每次看到这种 情况，我真的很想把开发的老哥揪回来问一句，你定义一个bean不香吗？

说到香，就不得不再说说我们新的真香--Jackson。fastjson在中文互联网之所以流行，顾名思义，它非常的fast。我做了一个简单的测试，分别使用fastjson和jackson，将一个Map转换成json字符串，测试结果如下

偶买噶，性能也相差无几。当然需要注意的是，自己封装jackson的工具类时，ObjectMapper最好写成单例，不然性能差不多会低上10倍吧。工具类的更换比业务逻辑的修改更容易踩坑。

说到坑，就不得不提Jackson的几个坑。在json字符串转换成bean时，jackson默认是大小写敏感的，也就是说，如果json中字段名是User，而bean的字段名是user，Jackson是不认识的，直接抛异常。解决起来倒是不复杂，ObjectMapper添加配置:
ObjectMapper mapper = new ObjectMapper();
mapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES,true);

此外，当json中的字段，bean中不存在时，jackson并不会忽略它，默认是抛出异常。稍微有点违反直觉。通过加配置也能解决：
ObjectMapper mapper = new ObjectMapper();
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);