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

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

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

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

所以說這不能說人家框架有問題，就像我們如果不了解Springweb的原理，寫出的接口出了問題，卻說Spring框架有問題，豈不是欲加之罪？

槽點2. copy為淺拷貝（拷貝對象的引用）

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

槽點3. Spring不同版本對屬性泛型處理方式不同

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

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

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

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

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

所以我覺得，這個問題頂多算是寫代碼不規范導致的。

性能

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

總結

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

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

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