麻了！不要再动不动就用BeanUtil.copyProperties了！！

最新推荐文章于 2025-12-26 18:13:00 发布

转载最新推荐文章于 2025-12-26 18:13:00 发布 · 171 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247573217&idx=3&sn=f9335a68a09199a93cd40b923a6107f4&chksm=fa4ba150cd3c2846db2f0f6cc5f5a13a8e6eef97c6838d4141df42cffd3585f45453695db6d4&scene=126&sessionid=0

文章标签：

#java #开发语言

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

来源：JAVA旭阳

前言

最近项目上要求升级一个工具包hutool的版本，以解决安全漏洞问题，这不升级还好，一升级反而捅出了更大的篓子，究竟是怎么回事呢？

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

事件回顾

我们项目原先使用的hutool版本是5.7.2，在代码中，我们的数据传输对象DTO和数据实体对象中大量使用了工具包中的BeanUtil.copyProperties(), 大体代码如下：

数据传输对象

@Data
@ToString
public class DiagramDTO {

    // 前端生产的字符串id
    private String id;

    private String code;

    private String name;
}

数据实体对象

@Data
@ToString
public class Diagram {

    private Integer id;

    private String code;

    private String name;
}

业务逻辑

public class BeanCopyTest {

    public static void main(String[] args) {
        // 前端传输的对象
        DiagramDTO diagramDTO = new DiagramDTO();
        // 如果前端传入的id事包含e的，升级后就会报错
        diagramDTO.setId("3em3dgqsgmn0");
        diagramDTO.setCode("d1");
        diagramDTO.setName("图表");

        Diagram diagram = new Diagram();
        // 关键点，数据拷贝
        BeanUtil.copyProperties(diagramDTO, diagram);
        System.out.println("数据实体对象：" + diagram);
        //设置id为空，自增
        diagram.setId(null);
        //保存到数据库中 TODO
        //diagramMapper.save(diagram);
    }
}

升级前，hutool是5.7.2版本下，执行结果如下图。

BeanUtil.copyProperties虽然字段类型不一样，但是做了兼容处理，所以业务没有影响业务逻辑。

升级后，hutool是5.8.8版本，执行结果如下图所示：

执行报错，因为升级后的版本修改了实现，增加了下面的逻辑，如果包含E, 就会抛错，从而影响了业务逻辑，同时这个id是否包含e又是随机因素，到了生产才发现，就悲剧了。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud
视频教程：https://doc.iocoder.cn/video/

分析探讨

我发现大部分人写代码都喜欢偷懒，在上面的场景中，虽然BeanUtil.copyProperties用的一时爽，但有时候带来的后果是很严重的，所以很不推荐这种方式。为什么这么说呢？

比如团队中的某些人偷偷改了数据传输对象DTO，比如修改了类型、删去了某个字段。用BeanUtil.copyProperties的方式压根无法在编译阶段发现，更别提修改的影响范围了，这就只能把风险暴露到生产上去了。那有什么更好的方法呢？

推荐方案

原始的get、set方式

我是比较推崇这种做法的，比如现在DiagramDTO删去某个字段，编译器就会报错，就会引起你的注意了，让问题提前暴露，无处遁形。

你可能觉得站着说话不腰疼，字段少好，如果字段很多还不得写死啊，我这里推荐一个IDEA的插件，可以帮你智能生成这样的代码。

话不多说，自己玩儿去~~

使用开源库ModelMapper

ModelMapper是一个开源库，可以很方便、简单地将对象从一种类型映射到另一种类型，底层是通过反射来自动确定对象之间的映射，还可以自定义映射规则。

private static void testModelMapper() {
        ModelMapper modelMapper = new ModelMapper();
        DiagramDTO diagramDTO = new DiagramDTO();
        diagramDTO.setId("3em3dgqsgmn0");
        diagramDTO.setCode("d1");
        diagramDTO.setName("图表");
        Diagram diagram = modelMapper.map(diagramDTO, Diagram.class);
    }

使用开源库MapStruct

MapStruct也是Java中另外一个用于映射对象很流行的开源工具。它是在编译阶段生成对应的映射代码，相对于ModelMapper底层放射的方案，性能更好。

@Mapper
public interface DiagramMapper {
    DiagramMapper INSTANCE = Mappers.getMapper(DiagramMapper.class);

    DiagramDTO toDTO(Diagram diagram);

    Diagram toEntity(DiagramDTO diagram);
}

private static void testMapStruct() {
    DiagramDTO diagramDTO = new DiagramDTO();
    diagramDTO.setId("3em3dgqsgmn0");
    diagramDTO.setCode("d1");
    diagramDTO.setName("图表");
    Diagram diagram = DiagramMapper.INSTANCE.toEntity(diagramDTO);
}

DiagramMapper接口使用了@Mapper注解，用来表明使用MapStruct处理
MapStruct中更多高级特性大家自己探索一下。

总结

小结一下，对象在不同层之间进行转换映射，很不建议使用BeanUtil.copyProperties这种方式，更加推荐使用原生的set, get方式，不容易出错。当然这不是将BeanUtil.copyProperties一棒子打死，毫无用武之地，在特定场景，比如方法内部对象的转换等影响小的范围还是很方便的。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）