你为何仍用 Fastjson？

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

我认为害怕来自于未知。

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

测试结果表明，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 也就没有标准的答案，各位还是结合自己的具体情况。