放心大胆的用，BeanUtils.copyProperties没有想象中的那么差

不知道从什么时候开始，大家对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年。希望大家都能像前者一样，在技术的道路不断进步。