背景
原本的FastJosn 是1.2.x 大家都知道 这个版本存在严重的漏洞，如果不升级那么系统就会有安全隐患，一旦哪天暴雷，后果肯定不堪设想。本着安全着想，必须升级到一个安全的版本（1.2.83）。
版本变更有风险，升级需谨慎
大的版本变更带来的功能差异肯定相差很大，这个自不必多想。小的版本迭代同样有些意向不到的变化。我们升级的时候，会考虑哪些风险呢？
- 类或者方法的变更
因为迭代过程中，可能会出现废弃的类和方法，所以会产生新的版本中可能会丢弃原来的类或方法。 - 功能变更
一般引入一个jar 它的定位肯定是清晰的，也就是常用的功能是相对稳定的。但是在一些细节上处理可能会存在一些差异或者说是版本的优化。如果我们不能知道这些变化，使用起来很容易出现一些我们意想不到的问题。 - 性能变更
通常迭代会针对上一个版本做一些优化或者是问题修复，功能的实现会出现不同，这个难免会带来一些性能上的差异。
。。。
综上，我们不难看出，有些变更是我们在编译的时候或者是在我们启动项目的时候报错就能发现的，这类风险相对非常小。但是有些风险是只有在运行期间才会暴露出来，这些就是赤裸裸的坑啊！
回归我们本次遇到的惨案吧！
我们升级的项目，使用了RestTemplate，使用也就算了，关键还使用了FastJSON 作为响应的解析器，作为解析器也就算了，关键是这个支持的mediaType类型还没有显示的写出来！升级前能正常通过RestTemplate 请求，因为FastJSON 中解析构造方法中指定了application/json，所以就算没有指定支持哪些mediaType 也没有关系。升级后，FastJson 支持类型是 */ *，巧的是RestTemplate 刚好校验住了。所以惨案就此发生了！
编译启动、接口中使用了FastJSON的都能正常使用。所以升级完后当然是开开心心的上线了，结果导致的事Resttemplate 瘫痪了！一场灾难就此发生！
后续
仅以此文记录本次惨案！希望大家都不会跳坑！本人也总结了下，在使用新的依赖或者升级的时候，我们可以在它对应的GitHub 的issue 中找下它对应的一些问题，再结合CSDN 等网上一些用户中遇到的问题，这样我们使用起这些依赖才会有更大的把握安全着陆。当然，如果时间足够的话，我们完全是可以拔一下源码，这样能了解足够的底层原理！
