記者：大爺您有什么特長呀？
fastjson:我很快。
記者：23423乘以4534等于多少？
fastjson:等于2343.
記者：？？
fastjson:你就說快不快吧！

這個略顯馬麗蘇的標題，各位看官將就著看吧。主要是怕被噴。fastjson真的很好，我用不用我喜不喜歡的，太不重要了，我只是覺得不適合我而已。 ?

話說以前GSON用得好好的，同事極力推薦我使用Fastjson,說很快云云。盡管我們的系統(tǒng)根本感知不出來這點速度差異。
之前也聽說Fastjson爆出來什么重大漏洞，但對我們基本沒什么影響，所以這一點倒是沒什么偏見。

然后在一個新項目上，腦抽抽，把gson換成了fastjson，還把spring boot默認支持的jackson換成了fastjson。
然后就開始遇到了一些問題。先聲明，這真不是尬黑，為了文章效果，故意網(wǎng)上扒些黑料拼湊起來，本文所提到的問題，都來源于本人最近項目的真實經(jīng)歷。

dateformat優(yōu)先級

本來是一個風和日麗的下午，一個非常簡單的改動需求。接口返回的時間只需要年月日日期類型不需要時分秒。
因為我配置全局時間格式化為yyyy-MM-dd HH:mmss,于是我愉快的在javabean的屬性上加了個注解。

@JSONField(format="yyyy-MM-dd") 復制代碼

本地測試一下，沒問題，提交到測試環(huán)境，搞定，完美。

然后就接到產(chǎn)品的疑問，改動呢？

我登上去看了一下，唉，沒改到啊，日期還是帶了時分秒。
我大意了啊，這么小的改動，又是在測試環(huán)境，就沒加驗證。

那么現(xiàn)在的直接問題是：fastjson關于時間配置在局部的配置沒有生效，使用的還是全局配置。

現(xiàn)象是，開發(fā)環(huán)境windows上沒有問題，測試環(huán)境linux上出現(xiàn)了問題。兩者有什么區(qū)別呢？系統(tǒng)問題？

既然懷疑是兩個系統(tǒng)導致的問題，那么就在idea里模擬一下linux系統(tǒng)。在 VM options 添加 -Dos.name=linux

這不能完全模擬linux系統(tǒng)，只針對通過System.getproperty("os.name")來判斷當前系統(tǒng)做某些操作的時候有用。

通過這種方式?jīng)]復現(xiàn)。

我又想到了遠程調(diào)試。
一陣操作猛如虎，遠程調(diào)試倒是能進斷點，只是斷點進不了第三方jar包的源碼。等于白搞。

得，還是回到源碼吧。拉下源碼，斷點，觀察JSONSerializer類，主要是writeWithFormat方法。沒有發(fā)現(xiàn)問題。
因為懷疑是系統(tǒng)導致的，在源碼中搜索'linux''unix'關鍵字，沒有發(fā)現(xiàn)。斷點整個流程重點觀察了一下這部份也沒有發(fā)現(xiàn)問題。

突然在 JSONSerializer.dateFormatPattern上發(fā)現(xiàn)了這段注釋。

這部份涉及到了調(diào)整dateformat的問題，重點在這個#1868,這通常是github的問題編號。

1.對于開源項目來說，解決了BUG，通常會把問題編號放到注釋里面去。前提是注釋有必要。通過問題編號可以看到問題的前因后果。

2.通常來說，對于github開源項目都有issue區(qū)，拿著這個到編號直接到issue一搜就能搜到。

3.但也有一些項級項目，如spark,flink是沒有issue區(qū)的，它們的類型問題發(fā)現(xiàn)描述追蹤都使用jira平臺。
如：issues.apache.org/jira/browse… ?在提交PR的時候標題也嚴格按照[jira 編號][spark 子模塊(如core/sql) title]的規(guī)則來。

所以拿著這個編號到issue區(qū)，不管有沒有issue區(qū)，也都可以直接到pullrequest區(qū)直接搜索，就算PR標題里沒有問題編號，PR描述肯定也是有的，只要是有嚴格PR流程的開源項目。

所以這個問題在這里

github.com/alibaba/fas…

相應的PR在這里

github.com/alibaba/fas…

通過ISSUES描述的已知信息，可以看出他遇到的問題跟我是一樣的，而這個問題早在2018年就提出了。但問題描述不太專業(yè)，沒有涉及到環(huán)境以及最重要的fastjson的版本問題。
而通過PR可知，這個問題最終在2020才解決，期間僅在ISSUES區(qū)提出的相同問題就有 #1868 #1968 #2029 #24524個。
解決問題的版本為：1.2.72.

這個信息很關鍵。我對照了我開發(fā)環(huán)境的版本，是高于1.2.72的，所以沒有出現(xiàn)測試環(huán)境的問題。
所以，柯南告訴我們，排除了所有可能性，剩下的哪怕再可笑，也是最終問題所在。
那就是，測試環(huán)境所用的fastjson版本是低于1.2.72的。
這種可能性是存在的，因為我們用的是maven打代碼包，依賴包單獨存在。
我最終在測試環(huán)境的依賴包目錄下發(fā)現(xiàn)了兩個Fastjson包，果然不出所料，有一個1.2.53的低版本，它就是罪魁禍首。

所以，最終這個問題有相當大的程度是由于我們團隊自身問題引發(fā)的。但通過解決這個問題的過程也發(fā)現(xiàn)了一些有意思的情況。

首先，F(xiàn)astjson在某一個版本為什么會引發(fā)這個問題。它肯定是某個PR改出問題的，rv,testcase覆蓋沒有到位。

其次，從試圖解決這個問題的3個PR的時間線，分別在2018年，2019年，2020年。說明，fastjson這個項目的contributor看起來有百來人，但其中過于依賴其中某1個或者某些主力人員。精力有限，某些優(yōu)先級不那么高的BUG只能放任。