BeanUtils.copyProperties：曾經是我的女神，現在是我的毒藥。

前言

BeanUtils.copyProperties十有八九是你這些年工作中用的很多的其中一個，不管是Apache的還是Spring的。

網上的解釋浩如煙海，我這邊用一個超簡單的例子直觀展示給你看。

以後就記住了，能不用就不用。

正文

1、網上的解釋

我收納了幾個網上最典型的解釋，也就是這個工具類的缺點，可以先回顧一下。

大致如下：

1、只能淺拷貝，簡單理解就是隻複製的參照，沒複製物件內容；

2、名稱和型別要匹配，不匹配的屬性會複製失敗；

3、效能一般，因為用了反射機制。

這裡面，其實對於我們來講，這個工具好不好用，理解第2點就足夠了。

2、名稱不匹配

假設一個user物件，有個屬性是手機號，那麼我們看看使用BeanUtils後是什麼效果。

這是原物件，定義聯絡方式是telePhone。

然後我們定義一個接收拷貝的物件

使用BeanUtils.copyProperties拷貝後效果如下：

可以看到，因為名稱少了一個字母，所以拷貝後聯絡方式是null。

如果是返回給前端的介面資料，欄位又多，這樣的問題會耽誤你不少時間。

3、型別不匹配

我們再換個測試方式，原物件有個age屬性是String型別。

而接收拷貝的物件，因為你的同事偷懶，誤以為不是String，就給個Integer型別。

看看效果，不會報錯。

但是age也是null，沒有複製成功。

4、如果遇到豬隊友

其實上面兩個就是典型的缺點了，那我們如果再極端點，假設你某天遇到了豬隊友。

你們有一個型別是金額，原物件型別是BigDecimal。

而豬隊友自己建立了一個VO，給你來個double型別，你覺得會報錯嗎？

假如這個金額傳的還挺大

看下效果

瑪德，直接錢沒了，你完了。

5、我怎麼用的

工作這麼多年，上面的坑我基本都踩過，有些是我踩別人的。

所以我挺早就開始像下面這麼用了，返璞歸真了。

沒錯，直接用IDEA的外掛自動生成setter，然後寫值。

什麼BeanUtils，什麼MapStruct，什麼ModelMapper，都再見！

靈活，可控，直觀，效能還好，欄位多也多不到哪裡去，中小企業的最佳選擇。

總結

我所在的網際網路公司，從前年開始就已經禁止使用BeanUtils.copyProperties了，因為坑了太多隊友。

有段時間也有專案用MapStruct，但是當對映變得複雜時，設定也相應複雜起來，而且錯誤資訊有時會不清晰。

所以最終我們還是返璞歸真了，用外掛簡化對映，人工賦值，降低維護難度，已被列入了公司的程式設計規範。

君子，不立於危牆之下，看得見摸得著的心裡才踏實。

---

喜歡就點贊關注↓↓↓，更多幹貨持續輸出。