微信图片可以直接提取文字加翻译？

文章目录：

• 为何要放弃fastjson?
• fastjson替代方案 三种json框架的特点性能对比最终选择方案
• 替换依赖时的注意事项 谨慎，谨慎，再谨慎做好开发团队和测试团队的沟通做好回归/接口测试考虑迁移前后的性能差异
• 使用Gson替换fastjson Json反序列化范型处理List/Map写入驼峰与下划线转换
• 迁移常见问题踩坑 Date序列化方式不同SpringBoot异常Swagger异常@Mapping JsonObject作为入参异常

注意：是否使用fastjson是近年来一个争议性很大的话题，本文无意讨论框架选型的对错，只关注迁移这件事中遇到的问题进行反思和思考。大家如果有想发表的看法，可以在评论区 理 性 讨论。

为何要放弃fastjson?

究其原因，是fastjson漏洞频发，导致了公司内部需要频繁的督促各业务线升级fastjson版本，来防止安全问题。

fastjson在2020年频繁暴露安全漏洞，此漏洞可以绕过autoType开关来实现反序列化远程代码执行并获取服务器访问权限。

从2019年7月份发布的v1.2.59一直到2020年6月份发布的 v1.2.71 ，每个版本的升级中都有关于AutoType的升级，涉及13个正式版本。

fastjson中与AutoType相关的版本历史：

• 1.2.59发布，增强AutoType打开时的安全性 fastjson
• 1.2.60发布，增加了AutoType黑名单，修复拒绝服务安全问题 fastjson
• 1.2.61发布，增加AutoType安全黑名单 fastjson
• 1.2.62发布，增加AutoType黑名单、增强日期反序列化和JSONPath fastjson
• 1.2.66发布，Bug修复安全加固，并且做安全加固，补充了AutoType黑名单 fastjson
• 1.2.67发布，Bug修复安全加固，补充了AutoType黑名单 fastjson
• 1.2.68发布，支持GEOJSON，补充了AutoType黑名单
• 1.2.69发布，修复新发现高危AutoType开关绕过安全漏洞，补充了AutoType黑名单
• 1.2.70发布，提升兼容性，补充了AutoType黑名单
• 1.2.71发布，补充安全黑名单，无新增利用，预防性补充

相比之下，其他的json框架，如Gson和Jackson，漏洞数量少很多，高危漏洞也比较少，这是公司想要替换框架的主要原因。
 

说实话，这种实现方式的确是一个很有想法，很大胆的设计，也的确支撑了上面数以千计的SaaS应用和salesforce千亿美金的市值。

只是，我不清楚从元数据到领域对象的映射，salesforce具体是怎么做的，是通过他们的语法糖apex?如果没有领域对象，他们的业务代码要怎么写呢?反正据在salesforce里面做vendor的同学说，他们所谓的low code，里面还是有很多用apex写的代码，而且可维护性一般。

anyway，我们绝大部分的应用都是面向确定问题域的，不需要像Salesforce那样提供“无边际”的扩展能力。在这种情况下，我认为，领域对象是最好的连接数据模型和业务逻辑的桥梁。
 

前言

大家好，又双叒叕见面了，我是天天放大家鸽子的蛮三刀。

在被大家取关之前，我立下一个“远大的理想”，一定要在这周更新文章。现在看来，flag有用了。。。

本篇文章是我这一个多月来帮助组内废弃fastjson框架的总结，我们将大部分Java仓库从fastjson迁移至了Gson。

这么做的主要的原因是公司受够了fastjson频繁的安全漏洞问题，每一次出现漏洞都要推一次全公司的fastjson强制版本升级，很令公司头疼。

文章的前半部分，我会简单分析各种json解析框架的优劣，并给出企业级项目迁移json框架的几种解决方案。

在文章的后半部分，我会结合这一个月的经验，总结下Gson的使用问题，以及fastjson迁移到Gson踩过的深坑。

 

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!