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，但是当映射变得复杂时，配置也相应复杂起来，而且错误信息有时会不清晰。

所以最终我们还是返璞归真了，用插件简化映射，人工赋值，降低维护难度，已被列入了公司的编程规范。

君子，不立于危墙之下，看得见摸得着的心里才踏实。

---

喜欢就点赞关注↓↓↓，更多干货持续输出。