不知道從什么時候開始，大家對Spring的BeanUtils.copyProperties口誅筆伐，似乎用了這個方法拷貝bean屬性就低人一等，代碼分分鐘就是一堆bug一樣。但我相信，這個方法在大家的項目中出場率一定不低。

今天我們來分析一下，BeanUtils.copyProperties那些常被人吐槽的點(diǎn)，是否真的有大家說的那么不堪。

槽點(diǎn)1. 不聲明屬性的get、set方法，屬性將copy失敗

首先我們要明白，BeanUtils.copyProperties中sourceBean和targetBean的屬性的拷貝，是通過反射中的Method完成的，所以如果Bean不聲明屬性的set和get方法，就不能進(jìn)行屬性間的copy。

所以說這不能說人家框架有問題，就像我們?nèi)绻涣私釹pringweb的原理，寫出的接口出了問題，卻說Spring框架有問題，豈不是欲加之罪？

槽點(diǎn)2. copy為淺拷貝（拷貝對象的引用）

BeanUtils.copyProperties的定位就是快速淺拷貝，對于大多數(shù)的場景而言，通過getset方式快速復(fù)制屬性，已經(jīng)基本能滿足我們的日常需求。如果有深拷貝的需求，那我們要做的應(yīng)該更換拷貝工具，而不是埋怨BeanUtils.copyProperties有bug。

槽點(diǎn)3. Spring不同版本對屬性泛型處理方式不同

@Data
public class SourceBean {
    private List<Integer> ids;
}

@Data
public class TargetBean {
    private List<String> ids;
}

從工具類的角度看，兩個類的屬性名相同，但是泛型類型不同，所以未進(jìn)行屬性復(fù)制。

這個問題從不同的角度看似乎都有其合理性。從用戶角度看，同一個名稱的屬性未復(fù)制值，這是個bug。但是從工具類角度看，不同的泛型就相當(dāng)于兩個屬性，不復(fù)制是合理的。

但是反過來想，如果工具類直接把屬性名相同的值進(jìn)行復(fù)制，而不校驗泛型，那么當(dāng)我們使用target的時候，發(fā)現(xiàn)獲取的值不是source中的類型，是不是又該埋怨工具類擅自做主了呢？

所以我覺得，這個問題頂多算是寫代碼不規(guī)范導(dǎo)致的。

性能

對于絕大部分場景來說，屬性復(fù)制不會對性能有特別大的影響，一般不會成為性能瓶頸。

總結(jié)

說了這么多，其實也并不是要大家無腦的去使用BeanUtils.copyProperties，而是希望大家在合適的場景選用合適的工具做合適的事。

我們常說，透過現(xiàn)象看本質(zhì)，能真正的理解其背后的復(fù)制原理，才能讓我們的編碼能力不斷提升，而不是人云亦云的說某某工具類不好用。

借用一位老哥的話：有的人干5年有5年的經(jīng)驗，有的人一個經(jīng)驗用5年。希望大家都能像前者一樣，在技術(shù)的道路不斷進(jìn)步。