MapStruct与手动映射性能对比实测

项目里新来的同事看到我们用 MapStruct 做对象转换，一脸不解地问我：“手写 getter/setter 不就几行代码的事吗？搞个注解处理器进来，项目编译速度都慢了，图啥？”

这确实是个好问题。在 Java 开发的日常中，尤其是在分层架构下，DO、DTO、VO 之间的属性拷贝简直是家常便饭。业务刚起步时，手写映射简单粗暴，但随着字段增多、嵌套复杂，这活儿就变成了纯粹的体力劳动。于是催生了各种工具：Apache BeanUtils、Spring BeanUtils、MapStruct……圈子里对它们的性能争论也一直没停过。

今天不忙着站队，咱们直接写个代码实测一下 MapStruct 和手动 Setter 到底有多大差距。顺便也看看它在面对复杂嵌套、List 转换时，编译生成的代码究竟长什么样，这样心里才有底。

先说测试环境：JDK 17，一台普通的 MacBook Pro，为了降低 JIT 干扰，每个场景跑 10 万次取均值。为了模拟真实业务，我建了一个带嵌套对象（比如用户包含地址列表）的 Source/DTO 结构，字段名保持一致。

测试场景一：单层简单对象映射
就是最简单的字段一一对应，没有嵌套，没有类型转换。手写逻辑就是最朴素的 `target.setXxx(source.getXxx())`。跑下来结果毫无悬念，MapStruct 的手写 Java Bean 代码与手写的 Setter 性能极其接近，甚至在某些极端循环次数下，MapStruct 生成的代码因为少了方法调用深度，反而快了那么一丢丢（虽然差距在微秒级别，几乎可以忽略）。

测试场景二：包含嵌套对象与 List 转换的复杂映射
这里才是分水岭。手写代码去处理嵌套 `Address` 列表时，你要自己 new 集合、写 for 循环、再逐个转换。MapStruct 呢？它生成的代码同样是纯手工级别的 for 循环加 new 对象逻辑。测试数据很直观，两者的耗时差异依然在 5% 以内。注意，这里说的是代码执行性能差异只有 5% 以内，而代码量差异则是 500% 以上。

搞清楚了性能底牌，咱就该聊聊为什么不用 BeanUtils。以前用 Apache BeanUtils 或 Spring 的 BeanUtils 搞转换，图省事。但那些工具底层大多是反射，反射有缓存还好，一旦碰到高频调用或者对象图很深，性能损耗就明显被拉大。而 MapStruct 是在编译期就生成了对应的实现类，运行时就是最传统的 Java 方法调用，自然不存在反射的开销。

在实际的社区讨论或者说“踩坑”过程中，我们往往会发现，关于 MapStruct 性能的争论已经过时了，真正的痛点或者说对技术的考量主要在以下两个点：

第一，编译期报错 vs 运行期报错。手写映射如果字段名字写错了，编译期间 IDE 就会飘红。用 MapStruct 如果源对象和目标对象字段对不上，默认策略是生成代码时字段为 null，这需要在 `@Mapper` 里做好配置，让同名映射尽量多对齐。有点让代码生成器背锅的感觉，其实还是得靠单元测试兜底。

第二，深拷贝的“甜蜜陷阱”。MapStruct 默认是浅拷贝，和手动写 Setter 行为一致。但千万别指望它帮你做深拷贝，如果你在映射里嵌套了一个 Map 或者复杂泛型，而目标字段类型又一样，它可能直接引用同一个对象。这块需要你显式声明自定义转换方法。所以，性能对比实测的结果其实指向一个更朴素的真理：**真正的性能瓶颈从来不是对象拷贝本身，而是你有没有用错工具，以及有没有搞清楚它生成的代码在干嘛。**

最后做个总结。如果你还在纠结要不要引入 MapStruct，请放心大胆地引入。它的性能测试结果和手动映射持平，几乎零损耗。手动映射只适合那些字段极少、变动极少的内部传输类；一旦遇到几十个字段的 DTO 转换，MapStruct 不仅能帮你省下写 Setter 的时间，还能避免漏拷贝的隐患。

当然，前提是你得理解它的映射机制，别在继承和多态场景里把它当成万能药。项目里多用一分编译期生成代码，运行时就能少一份反射的挣扎。这波实测，不亏。