[[277840]]

背景

最近項(xiàng)目中在和第三方進(jìn)行聯(lián)調(diào)一個(gè)接口，我們這邊發(fā)送http請(qǐng)求給對(duì)方，然后接收對(duì)方的回應(yīng)，代碼都是老代碼。根據(jù)注釋，對(duì)方的SDK中寫好的Request類有一個(gè)無(wú)法序列化的bug，所以這邊重新寫了一個(gè)Request類，基本屬性都是相同的，但是重點(diǎn)是有一個(gè)屬性是靜態(tài)內(nèi)部類，還有兩個(gè)是list屬性，類似于下面這樣：

AddRequest就是我們自己重寫的請(qǐng)求類，他們SDK中的請(qǐng)求類是MixAddRequest，我們組裝好請(qǐng)求參數(shù)后利用Spring的BeanUtils的copyProperties方法將AddRequest中的屬性拷貝到MixAddRequest，然后發(fā)送請(qǐng)求。到此為止，照理說一切完美

結(jié)果請(qǐng)求失敗，納尼?對(duì)方說缺少一個(gè)必要的字段，參數(shù)校驗(yàn)不通過，一查字段名稱，是Ticket這個(gè)類里面的某個(gè)字段，趕緊看代碼，心里充滿對(duì)老代碼的自信，想著一定是哪里搞錯(cuò)了，或者是他們那邊偷偷動(dòng)了代碼，把字段從可選改為了必選，嘿嘿。

果然在代碼里找到了設(shè)置的地方，這下應(yīng)該是他們的問題確信無(wú)疑了，再開一把調(diào)試，準(zhǔn)備宣判他們的死刑。結(jié)果發(fā)現(xiàn)發(fā)給他們的請(qǐng)求就是沒有這個(gè)字段。。。中間只有一個(gè)Spring的copy屬性的方法，當(dāng)時(shí)覺得很詭異。

由于中間只有這么一行代碼，玄機(jī)肯定在這里面，初步懷疑是兩個(gè)靜態(tài)內(nèi)部類不同導(dǎo)致，所以自己寫Demo，準(zhǔn)備搞一把這個(gè)BeanUtils的copyProperties方法，寫了兩個(gè)類和一個(gè)Main，@Data和@ToString是lombok插件的注解，這里用來自動(dòng)生成getter和setter方法以及toString方法。

這里遇到了第一個(gè)坑，一開始圖省事，屬性寫為public，想著省掉了getter和setter方法，沒加@Data注解，結(jié)果運(yùn)行完test2所有屬性都為null，一個(gè)都沒copy過去，加上@Data繼續(xù)跑，果然，基本屬性(String)復(fù)制過去了，但是內(nèi)部類在test2中還是null。那就驗(yàn)證了真的是內(nèi)部類的問題，有點(diǎn)不敢相信自己的眼睛，畢竟線上跑了這么久的代碼。。。

知道了問題，總要想著怎么解決吧，所以需要單獨(dú)設(shè)置一下內(nèi)部類，單獨(dú)copy，如果內(nèi)部類的bean屬性較多或者遞歸的bean屬性很多，那可以自己封裝一個(gè)方法，用于遞歸拷貝，我這里只有一層，所以直接額外copy一次。

記得內(nèi)部類的屬性也是要有setter方法的，不然也會(huì)導(dǎo)致copy失敗，大家還記得我開頭說到還有兩個(gè)List屬性的吧，為什么要提到這個(gè)呢?你猜。

其實(shí)list里面的兩個(gè)類也都是重寫的內(nèi)部類，他們也是不同的，當(dāng)時(shí)他們卻順利copy過去了，為什么呢?因?yàn)閖ava的泛型只在編譯期起作用，在運(yùn)行期，list屬性就是一個(gè)存放Object的集合，在copy后，MixAddRequest的orders屬性其實(shí)是一個(gè)Order類的集合，但卻不是自己內(nèi)部類的集合，是AddRequest的內(nèi)部類Order的集合，但因?yàn)閷?duì)方是解析json的，所以沒有發(fā)生錯(cuò)誤。。。

總結(jié)

1.Spring的BeanUtils的CopyProperties方法需要對(duì)應(yīng)的屬性有g(shù)etter和setter方法;

2.如果存在屬性完全相同的內(nèi)部類，但是不是同一個(gè)內(nèi)部類，即分別屬于各自的內(nèi)部類，則spring會(huì)認(rèn)為屬性不同，不會(huì)copy;

3.泛型只在編譯期起作用，不能依靠泛型來做運(yùn)行期的限制;

4.最后，spring和apache的copy屬性的方法源和目的參數(shù)的位置正好相反，所以導(dǎo)包和調(diào)用的時(shí)候都要注意一下。