Fastjson合集：从踩坑到真香，我的血泪升级史
说实话,提到 Fastjson合集，我这心里真是五味杂陈，你要是 Java 后端开发，大概率跟我一样，跟这家伙打过不少交道吧？哎，别急着划走，今天我不是来念官方文档的，就想跟你唠唠我跟 Fastjson 这些年“相爱相杀”的故事，顺便把这个 Fastjson合集 里那些容易踩的坑、真香的技巧，都给你盘一盘。
一开始，谁不是图它快呢？
记得刚入行那会儿,老项目用的 Jackson，后来换了个新项目，技术选型会上，组长一拍桌子：“用 Fastjson，快！” 真的，那时候 Fastjson 高性能 JSON 库”的代名词啊，序列化反序列化嗖嗖的，代码写起来也短，JSON.toJSONString(obj) 一行搞定，多爽，于是我就一头扎进了 Fastjson 的怀抱。
可是好景不长……有一次线上突然告警，我一脸懵地查日志，发现是 Fastjson 反序列化的时候，把某个字段的类型搞错了，直接抛异常，那时我才意识到，Fastjson合集里最经典的安全问题、AutoType 问题，可不是闹着玩的，唉，年轻啊，光图快，没看坑。
那些年我踩过的 Fastjson 坑
先给你列几个我印象最深的,你看看是不是也中过招：
- 空字段被吞了：默认情况下，Fastjson 序列化时会把 null 值的字段直接忽略，结果前端小哥哥跑来问我：“你这接口怎么少个字段啊？” 我一看，哦，
SerializerFeature.WriteMapNullValue没加，得，加吧。 - 日期格式乱七八糟：默认序列化 Date 出来是一串时间戳，前端解析起来直骂娘，后来老老实实指定
SerializerFeature.WriteDateUseDateFormat，或者自己写个 Serializer。 - 循环引用直接栈溢出：两个对象互相引用，
JSON.toJSONString一调，啪，StackOverflowError，这时候就得用SerializerFeature.DisableCircularReferenceDetect，但你也得小心，禁用了之后可能死循环。 - AutoType 安全漏洞：这个是最要命的，攻击者构造恶意 JSON，利用 AutoType 加载恶意类，直接 RCE，那段时间 Fastjson 频繁爆漏洞，我们连夜升级版本，跟打地鼠似的，所以现在你要是用 Fastjson，一定要用 1.2.83 之后的版本，或者直接上 Fastjson2。
你看看,这些坑是不是每个都让人头大？可话说回来，谁让咱当初选了它呢，只能一边骂一边修，后来我就养成了习惯，每次用 Fastjson 之前，先把 Fastjson合集 里的注意事项翻一遍，省得再翻车。
Fastjson2 来了，真香警告！
本来我已经打算弃坑了,转投 Jackson 或者 Gson 的怀抱，结果呢？阿里又搞了个 Fastjson2，性能直接起飞，比 Fastjson 1.x 快了不是一点半点，而且安全性也大大提升，我抱着试试看的心态在新项目里用了用，哎哟，真香！
- API 基本兼容，迁移成本低。
- 默认就开启了很多安全特性,不用整天提心吊胆。
- 对 Kotlin、GraalVM 支持也更好。
- 序列化/反序列化 JSONB 格式，速度简直离谱。
现在我的态度就是：新项目直接上 Fastjson2，老项目如果还在用 Fastjson 1.x，赶紧升级到安全版本，或者慢慢迁移。Fastjson合集里我也专门整理了一份 Fastjson2 的迁移指南，有需要的朋友可以自取。
最后说几句掏心窝的话
其实吧,技术这东西没有绝对的好坏，Fastjson 曾经因为快而风靡，也因为安全问题被骂得很惨，但你不能否认，它在 Java JSON 生态里留下了浓墨重彩的一笔，现在有了 Fastjson2，算是涅槃重生了。
如果你还在用 Fastjson，别怕，把版本升上去，该加的 Feature 加上，该避的坑避开，如果你已经转投别的库，那也没关系，多了解一个总没坏处，毕竟，Fastjson合集这个东西，说不定哪天面试或者接老项目就用上了呢。
好了,今天就唠到这儿，如果你也有跟 Fastjson 的故事，或者踩过什么奇葩的坑，欢迎在评论区跟我分享，咱们下期见！拜拜～