你为何仍用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也就没有标准的答案，各位还是结合自己的具体情况。
