再见！Fastjson！

你为何仍用Fastjson？

原因可以说出5678种，总而言之言而总之，你不（敢）切换的原因或许只有一个：Fastjson的静态方法调用用着省心；最重要的是，对其它JSON库（如Jackson/Gson）并不熟悉不敢切换。

我认为害怕来自于未知。

 

也可能你觉得Fastjson的速度快，我做了一个简单测试：

库名称	测试样例	序列化时间（ms）	反序列化时间（ms）
Fastjson	1万个JavaBean对象	125	135
Gson	1万个JavaBean对象	150	145
Jackson	1万个JavaBean对象	135	130
Fastjson	1万个简单的JSON对象	115	130
Gson	1万个简单的JSON对象	130	140
Jackson	1万个简单的JSON对象	120	125

测试结果表明，Fastjson的序列化和反序列化性能略优于其他两个库，但差距并不大。

可能速度的确快那么一丢丢，但是再生产中，又有多少业务是海量数据或者说需要fastjson来处理呢？

换句话说，既然差异性这么小，Fastjson一味的强调它是最快的真的有意义吗？

正文

坊间在某坛里看到这样一句言论：若你还依赖于使用Fastjson，那么你大概率还只是初/中级水平。这句话必然让Fastjson的忠实用户火冒三丈，抄起家伙嘎嘎就是干。话出必然有因，那么这句话是否真的言过于词呢？接下来就絮叨絮叨

安全漏洞

Fastjson在处理JSON字符串时，存在一些安全漏洞。例如，Fastjson中的反序列化漏洞可能会导致远程代码执行，这意味着攻击者可以利用漏洞远程执行恶意代码，从而危及应用程序和用户的安全。

 

此外，Fastjson在处理非标准JSON格式时也容易受到攻击。攻击者可以通过构造特定的JSON字符串来绕过Fastjson的解析和验证，从而导致安全问题。

不易于调试和排错

Fastjson在解析和序列化JSON数据时，可能会出现一些错误，而这些错误很难被发现和排除。由于Fastjson的错误消息很难理解，因此，当出现错误时，开发人员可能需要花费更多的时间来调试和排错。

相比之下，其他JSON库（例如Jackson）提供了更详细和易于理解的错误消息，这使得调试和排错变得更加容易。

代码质量和可维护性

Fastjson的代码质量和可维护性也是一些开发人员放弃它的原因。Fastjson的代码中存在大量的重复代码和复杂的逻辑，这使得它难以维护和扩展。这也意味着，当您需要进行一些自定义的序列化和反序列化时，您可能需要编写更多的代码，从而增加了代码的复杂性和维护难度。

相比之下，其他JSON库（例如Jackson）采用了更简洁和模块化的代码结构，这使得它更易于维护和扩展。

结语

在工具选择上从来都没有最合适，只有更合适，这是一个仁者见仁智者见智的问题，至少单从安全性这一角度来说，Fastjson已经输了，写这篇文章的目的只是为了记录Fastjson曾经辉煌的历史和存在问题，并不是为了和大家抬杠。同样的，Fastjson还是Jackson也就没有标准的答案，各位还是结合自己的具体情况。