企业官网建设流程全解析

做后端这些年，业务代码里最烦人的不是复杂的算法，也不是高并发设计，而是每天都要面对的那一堆对象转换。DTO转Entity、Entity转VO、外部接口返回转内部模型，一个字段的重命名能牵出七八个类的改动，改完还容易漏掉某个映射字段，编译不报错，运行到那个接口才发现问题。Spring Boot 3加Java 17这套组合已经是新项目的常规配置，在这套体系里做对象映射，我最后选定了编译期代码生成的方案，也就是MapStruct。这篇文章就从改造前的痛点讲起，把方案选型、依赖配置、基础映射、复杂场景、踩坑排查完整走一遍，给正在纠结对象映射方案的读者一个可直接落地的参考。

1. 对象映射痛点：业务代码里最没技术含量却最耗精力的部分

1.1 日常开发里绕不开的三个转换场景

后端业务开发中，对象转换几乎无处不在。最常见的是分层架构里的实体与视图模型转换。某个订单查询接口，数据库查出来的是Order实体，但不能直接返回给前端，因为里面有内部字段、敏感信息或者不友好的格式，需要转成OrderVO。这个转换过程，最初大家都是手写getter/setter。

第二个场景是入参转换。前端传过来的CreateOrderDTO，需要转成Order实体落库。DTO和实体的字段往往不是一一对应的——比如前端传shopId，实体里存的是shopCode，或者DTO里几个字段要合并成实体的一个字段。手写代码的时候还能勉强应付，字段一多就烦躁。

第三个场景是外部接口对接。对接某个第三方平台时，人家返回的是JSON，我们定义了自己的领域模型，中间需要一个转换层。这种场景下字段命名风格经常不一致，对方用下划线，我们用到驼峰，手工转换代码写起来又臭又长。

这些转换需求单独看都不复杂，但架不住量大。某电商项目改造时我统计过，一个订单模块涉及二十多个类，转换方法上百处，手写的映射代码接近两千行，其中有大量是重复的getter/setter拼装。

1.2 手写映射代码隐藏的三个真实代价

手写代码的第一代价是样板代码膨胀。一个字段稍微多一点的转换方法，比如十几个字段，写出来就是一大坨get/set，看着就觉得浪费时间。代码评审的时候没人会细看这坨逻辑，但它确实占据了文件的大部分篇幅，挤占了真正核心业务逻辑的阅读空间。

第二个代价是维护成本。实体类加了字段，所有相关的VO、DTO都得跟着加映射代码。某个字段改了名字，IDE的重构功能只能帮你改当前文件里的引用，其他类里的转换代码只能靠全局搜索手动改。漏改一个，编译不报错，运行时空指针或者字段丢失，前端排查半天才发现是后端转换漏了字段。

第三个代价是深层拷贝缺失。手写getter/setter大多是浅拷贝，嵌套对象还是同一个引用。如果后续代码修改了嵌套对象的值，原对象的对应字段也被改了，这种隐蔽bug排查起来相当痛苦，因为问题的表象往往出现在几百行之外。

1.3 反射工具类为什么看着省事其实有坑

后来大家开始用BeanUtils、BeanCopier这类反射工具。代码确实简洁了，一行copyProperties搞定，但用久了会发现另一堆问题。

反射的性能开销是绕不过去的。虽然现代JVM对反射做了很多优化，但相比直接方法调用还是有量级差距。某个高流量查询接口，每次请求都要做几次对象转换，压测时反射方案比编译期方案吞吐量差了不少。更重要的是反射方案大多是浅拷贝，不解决嵌套对象的深拷贝问题。

最致命的是静默失败。字段类型不一致、名字对不上时，BeanUtils的copyProperties默认忽略掉不一致的字段，不报错。这意味着你的转换代码永远无法发现字段映射遗漏的问题，只能靠测试去验收。曾有个同事调接口发现返回数据里creatTime一直为空，查了半天才发现实体字段叫createdAt，VO字段叫createTime，BeanUtils直接忽略了不匹配的字段，接口本身也没报错。

2. 方案选型：为什么在Spring Boot 3场景下推荐编译期对象映射

2.1 市面主流对象映射方案横向对比

市面上常见的对象映射方案大致可以分三类：手写代码、运行期反射、编译期代码生成。手写代码太啰嗦，前面已经说过。运行期反射的代表是Spring的BeanUtils和Apache Commons BeanUtils，以及Cglib的BeanCopier。编译期代码生成的代表是MapStruct，还有相对小众的ModelMapper。

用表格对比会更直观：

看到这个对比，选型方向基本就清晰了。手写代码维护成本太高，运行期方案性能不够好且没有编译期校验，MapStruct在性能、功能、维护性之间找到了一个很好的平衡点。

2.2 编译期生成和运行期反射的差别在哪

理解MapStruct原理其实很简单：它利用Java注解处理器，在编译阶段读取@Mapper注解和@Mapping注解，然后生成接口的实现类。生成的代码就是你要手写的那种getter/setter，只不过由工具自动生成，编译后class文件里就有一份实实在在的实现类，运行时调用跟手写代码没有区别。

举个直观的例子，OrderMapper接口编译后，target/generated-sources/annotations目录下会生成OrderMapperImpl类，打开看就是标准的get/set逻辑。这意味着你有机会在编译失败的时候看到具体哪个字段没有映射，也能在生成的代码中确认映射逻辑是否符合预期。

反射方案是运行期才能确定调用哪些方法，每次调用都需要一些内省的逻辑，性能自然有差距。而且反射无法在编译期发现字段名的拼写错误，运行期发现不了就一直静默空值。

Spring Boot 3默认使用Java 17及以上版本，新项目中很多团队还会启用record等新特性。MapStruct对record的映射支持比较完善，同时可以配合Spring的依赖注入将Mapper纳入容器管理，这是很契合的搭配。

2.3 Spring Boot 3场景下的两个额外优势

第一个优势是编译期校验带来的交付质量提升。字段映射漏了、类型写错了、源字段不存在了，编译直接报错，而不是留给测试阶段去发现。某次我们重构一个订单实体的字段名，重构后发现三个Mapper编译报错，几分钟就修完了。如果是手写代码或者反射方案，这个问题可能要在联调时才暴露。

第二个优势是注入无缝。MapStruct接口配上componentModel = "spring"后，生成的实现类会自动加@Component注解，可以通过@Autowired直接注入使用，和Spring Boot 3的整套依赖注入体系配合得很自然。对于Spring Boot 3项目的维护者来说，不需要额外理解一套新的框架概念。

3. 项目实战落地：依赖配置到第一个Mapper跑通

3.1 Maven依赖与注解处理器配置

Spring Boot 3项目通常是基于spring-boot-starter-parent管理的，Maven依赖配置并不复杂。在pom.xml中引入MapStruct的依赖和注解处理器。

<properties> <java.version>17</java.version> <mapstruct.version>1.6.3.Final</mapstruct.version> </properties> <dependencies> <dependency> <groupId>org.mapstruct</groupId> <artifactId>mapstruct</artifactId> <version>${mapstruct.version}</version> </dependency> </dependencies>

单独加依赖就够了，spring-boot-starter-parent帮我们配置了maven-compiler-plugin的默认行为。但如果项目里同时使用了Lombok，需要额外显式配置annotationProcessorPaths，并且顺序有讲究。

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <annotationProcessorPaths> <path> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>${lombok.version}</version> </path> <path> <groupId>org.mapstruct</groupId> <artifactId>mapstruct-processor</artifactId> <version>${mapstruct.version}</version> </path> </annotationProcessorPaths> </configuration> </plugin>

这个顺序问题我特别标出来，是因为踩过一次坑。Lombok的注解处理器必须在mapstruct-processor之前。MapStruct的注解处理器在读取源文件时，需要拿到Lombok生成后的完整类信息，顺序反了，MapStruct只能看到没有setter/getter的原始类，生成的实现类一堆编译错误。网上很多报错帖子的根源就在这里。

如果有同事询问为什么不用starter封装，我的习惯是直接引依赖，不额外封装。MapStruct的版本由父工程统一管理就好，封一层starter反倒增加排查复杂度。

3.2 编写第一个Mapper：注解与组件模型选择

依赖配置好后，来一个最简单的例子。假设有一个用户实体User：

@Data public class User { private Long id; private String username; private String email; private String phone; private LocalDateTime createTime; }

需要转换的视图对象UserVO：

@Data public class UserVO { private Long id; private String username; private String email; private String phone; private LocalDateTime createTime; }

两个类字段完全一致，Mapper接口只需要一行：

@Mapper(componentModel = "spring") public interface UserMapper { UserVO toVO(User user); }

@Mapper注解是关键。componentModel = "spring"告诉MapStruct生成一个Spring管理的Bean，实现类会自动加@Component注解。编译后，在target/generated-sources/annotations/com/example下能看到UserMapperImpl：

@Component public class UserMapperImpl implements UserMapper { @Override public UserVO toVO(User user) { if (user == null) { return null; } UserVO userVO = new UserVO(); userVO.setId(user.getId()); userVO.setUsername(user.getUsername()); userVO.setEmail(user.getEmail()); userVO.setPhone(user.getPhone()); userVO.setCreateTime(user.getCreateTime()); return userVO; } }

注意它对null源对象做了判空处理，返回null而不是抛空指针。这个细节很贴心，手写代码很容易忽略。

3.3 接口中直接注入Mapper使用

项目启动后，UserMapper被Spring管理，服务类里直接注入：

@Service @RequiredArgsConstructor public class UserQueryService { private final UserMapper userMapper; public UserVO getUserById(Long id) { User user = userRepository.findById(id).orElse(null); return userMapper.toVO(user); } }

有同事会纠结用@Resource还是@Autowired，我的习惯是用构造器注入，Spring Boot 3下配合Lombok的@RequiredArgsConstructor非常顺。如果你在某个遗留项目里不方便改造成构造器注入，直接在字段上加@Autowired也完全没问题，MapStruct生成的Bean在容器里就是个普通组件。

实际跑起来后最直观的感受是：没有运行时配置、没有XML、没有反射调用链，Mapper就是接口加注解，转换逻辑在编译期已经写死了。代码量比手写DTO转换少了大概一半以上，字段增删之后重新编译，编译器会直接告诉你哪些映射没处理。

4. 核心映射场景：从简单字段到复杂业务转换

4.1 字段名不一致时的@Mapping配置

真实业务里字段名完全一致的情况很少，最常见的就是实体字段叫username，VO字段叫nickname。MapStruct提供@Mapping注解做显式映射。

@Mapper(componentModel = "spring") public interface UserMapper { @Mapping(target = "nickname", source = "username") UserVO toVO(User user); @Mapping(target = "username", source = "nickname") User toEntity(UserVO vo); }

target表示目标对象的字段名，source表示源对象的字段名。反向映射也好理解，DTO转实体的时候反过来写。字段名不一致的转换在这里被非常清楚地声明出来，代码即文档的效果比手写getter/setter要强很多。

多字段不一致时就在方法上叠加多个@Mapping：

@Mapping(target = "nickname", source = "username") @Mapping(target = "displayEmail", source = "email") UserVO toVO(User user);

这种写法还有个好处：转换关系是集中声明的，代码评审时扫一眼就能看出两端字段的对应关系，不像手写转换代码要逐行核对。

4.2 忽略字段与固定值填充

有些字段不需要从源对象复制，比如创建时间要自己在转换时填，逻辑删除标志固定填false。MapStruct提供了ignore。

@Mapping(target = "id", ignore = true) @Mapping(target = "createTime", ignore = true) @Mapping(target = "deleted", constant = "false") User toEntity(UserDTO dto);

三个注解配合使用的场景很典型：新增用户时id由数据库生成，createTime由数据库或填充字段处理，deleted字段固定为false。constant = "false"用来填入常量值，Spring上下文里不会有多余逻辑，编译期就写死进实现类了。

constant支持字符串形式的固定值，如果目标字段是数字类型，写constant会做类型转换吗？实测发现，MapStruct会根据目标字段类型自动把字符串转换为对应类型，这个特性在处理通用的status、type这种字典值字段时非常好用。

4.3 类型映射和日期格式化

LocalDateTime和String之间转换是个高频需求。数据库实体字段一般是LocalDateTime，VO需要返回格式化字符串给前端。MapStruct为常见类型内置了转换器。

@Mapper(componentModel = "spring") public interface OrderMapper { @Mapping(target = "createTime", source = "createTime", dateFormat = "yyyy-MM-dd HH:mm:ss") OrderVO toVO(Order order); }

加上dateFormat后，MapStruct在处理源字段和目标字段的类型转换时，会自动调用日期格式化，生成代码里会调用一个时间格式化工具类。底层是SimpleDateFormat还是DateTimeFormatter取决于类型，但封装得足够好，日常使用完全不用关心。

数字和字符串互转也是一样，源字段是BigDecimal，目标字段是String，MapStruct会自动调用toString方法。

4.4 嵌套对象与集合映射

嵌套对象映射是最容易出错的场景之一。有一个常见误区：Order里有用户信息，OrderVO里也想放用户名。新手会用@Mapping(target = "userName", source = "userName")来配置，编译直接报错。正确姿势是指定嵌套路径。

@Mapping(target = "userName", source = "user.name") @Mapping(target = "shopName", source = "shop.name") OrderVO toVO(Order order);

source = "user.name"表示从order.getUser().getName()取值，源对象路径支持点号嵌套。MapStruct在生成实现类时会自动判空，如果user为null，生成的代码会做null检查然后返回null，不会因为嵌套对象为null而抛空指针。这个细节实测过，生成的代码中会有嵌套判空逻辑，安全性比手写代码高很多。

集合映射是另一个高频场景。查询列表接口，List 要转成List ，MapStruct只需新增一个方法：

List<UserVO> toVOList(List<User> users);

MapStruct会自动复用单对象映射方法，对集合中的每一个元素调用toVO。不需要额外的循环逻辑。

如果还要处理分页对象，比如Spring Data的Page 要转成Page ，可以多声明一个默认方法组合：

default Page<UserVO> toVOPage(Page<User> users) { return users.map(this::toVO); }

这种组合方式不算MapStruct的核心能力，但代码量也很少，因为在接口里声明default方法，是Java接口的默认能力。

5. 进阶技巧：多参数映射、自定义转换器与复杂场景

5.1 多个源对象组合映射

很多业务场景下，目标对象的字段来自多个源对象。典型场景是生成订单详情VO，订单基本信息来自Order实体，买家信息来自User实体，卖家信息来自Shop实体。手写代码通常是串行调用几个转换方法再合并，MapStruct支持多参数映射。

@Mapper(componentModel = "spring") public interface OrderMapper { @Mapping(target = "orderId", source = "order.id") @Mapping(target = "orderStatus", source = "order.status") @Mapping(target = "userName", source = "user.name") @Mapping(target = "shopName", source = "shop.name") OrderDetailVO toDetailVO(Order order, User user, Shop shop); }

当某个字段在多个源对象中都存在时，需要明确指定source，否则编译报警告或者直接报错，这其实是好事，提前发现歧义比运行期猜强得多。

实践中我还经常用到@Context参数，它用来向转换方法传递上下文信息而不参与映射本身。例如当前操作人的ID，在实体转VO时需要把操作人ID带入VO，但对实体的映射不需要操作人ID：

@Mapping(target = "operatorId", source = "order.operatorId") OrderDetailVO toDetailVO(Order order, @Context Long operatorId);

@Context修饰的参数不会直接参与字段映射，但可以在自定义转换方法中读取它。

5.2 自定义类型转换：default方法解决字典翻译问题

字典翻译是后端开发中绕不开的业务场景。实体里存的是code，VO要展示的是name，比如订单状态status存的是Integer，前端要显示“待支付”“已发货”。MapStruct支持在Mapper接口中声明default方法处理自定义类型转换。

@Mapper(componentModel = "spring") public interface OrderMapper { @Mapping(target = "statusText", source = "status") OrderVO toVO(Order order); default String mapStatus(Integer status) { if (status == null) { return null; } switch (status) { case 0: return "待支付"; case 1: return "已支付"; case 2: return "已发货"; case 3: return "已完成"; default: return "未知"; } } }

MapStruct发现源字段status是Integer，目标字段statusText是String，会自动寻找可用的智能转换。default方法mapStatus的签名正好匹配，生成代码时会调用这个default方法。这种写法比表达式写法更适合处理复杂逻辑，因为写在default方法里可以加条件判断、支持IDE调试、方便单测。

但要注意default方法的命名不是随便取的。MapStruct的匹配规则是基于源类型和目标类型，方法名不要紧，重点是参数类型和返回类型要匹配。比如mapStatus(Integer)返回String，正好处理Integer到String的转换，方法名叫convertStatus、statusToString都可以。

5.3 表达式映射与转型的取舍

有些转换逻辑用一行Java表达式就能搞定，比如时间戳转成某个特殊格式。MapStruct支持expression属性。

@Mapping(target = "createTimestamp", expression = "java(order.getCreateTime().toEpochMilli())") OrderVO toVO(Order order);

expression里写的是Java代码片段，需要以java()开头，括号里放表达式。这个特性很灵活，但我不建议滥用。它把逻辑藏在注解的字符串里，编译期无法检查表达式合法性，写错了要运行期才能暴露。超过一行逻辑，还是拆到default方法里更稳妥。

另一个实用特性是@Named给default方法起别名，配合qualifiedByName指定调用哪个转换器，解决类型不唯一的情况：

@Mapper(componentModel = "spring") public interface UserMapper { @Mapping(target = "statusText", source = "status", qualifiedByName = "statusText") UserVO toVO(User user); @Named("statusText") default String mapStatusText(Integer status) { return status == 1 ? "启用" : "禁用"; } }

当Integer转String存在多个候选default方法时，必须用qualifiedByName指定，否则编译警告甚至报错。

5.4 更新现有对象：@MappingTarget的用法

除了创建新对象，还有一个高频场景是把DTO的数据更新到已有的实体上。手动写法是逐个set，代码长且容易漏字段。MapStruct支持@MappingTarget。

@Mapper(componentModel = "spring") public interface UserMapper { void update(@MappingTarget User user, UserDTO dto); }

这个方法的特别之处在于没有返回值，生成的实现类会直接修改传入的user对象，把dto中非null的字段复制过去。实际使用时，配合事务场景非常好用，从数据库查出User实体，用DTO数据局部更新，再交给JPA或MyBatis去持久化，避免了先查出再手动改字段的样板代码。

需要注意MapStruct生成的update方法，默认行为是直接覆盖目标对象字段。如果希望为null的源字段不覆盖目标字段，需要额外配置NullValuePropertyMappingStrategy：

@Mapper(componentModel = "spring", nullValuePropertyMappingStrategy = NullValuePropertyMappingStrategy.IGNORE) public interface UserMapper { void update(@MappingTarget User user, UserDTO dto); }

IGNORE表示源字段为null时不更新目标字段，这个策略在部分更新场景下非常实用，能避免前端只传了部分字段却把其他字段清空的问题。

5.5 与Lombok协作时的编译顺序迷局

前面提到了annotationProcessorPaths的顺序问题。在实际项目里，我遇到的最多问题就是Lombok和MapStruct一起使用时，编译报“找不到符号”或者生成的实现类里全是空方法。排查思路一般是先确认Lombok版本，再确认MapStruct版本，最后确认annotationProcessorPaths的声明顺序。

Spring Boot 3.x默认管理的Lombok版本，跟MapStruct 1.6.x配合目前没有遇到兼容性问题。如果是老项目升级，我建议把这两者都升级到当前稳定版本，不要单独锁定老版本。有个同事遇到过一个诡异情况：Lombok 1.18.20和MapStruct 1.4.2能编译，但生成的实现类里所有setter方法都被跳过。升级MapStruct到1.6.x后，问题就消失了，大概率是老版本MapStruct对较新Lombok生成的accessor信息解析不完整。

编译顺序上，如果不是用spring-boot-starter-parent管理的版本，需要留意maven-compiler-plugin编译参数。直接用IDE内嵌编译器时，IDEA对annotationProcessorPaths的解析和Maven命令行可能不太一样。经验是：优先在Maven命令行验证一遍能否完整编译，再回到IDE，必要时在IDEA设置中勾选Enable annotation processing。

6. 常见问题与排查技巧实录

6.1 编译报错Unmapped target property怎么处理

这是使用MapStruct后最常见的报错信息。当源对象和源字段无法完全匹配目标对象的字段时，编译器会报类似这样的错误：

Unmapped target property: "nickname".

出现这个错误通常是三种情况。

第一种情况是确实漏了映射，修复方法就是补上@Mapping注解，指定source来源。

第二种情况是目标字段不需要从源对象复制，比如id、createTime这些字段，修复方法是在@Mapping里加ignore = true。

第三种情况是目标字段有默认值处理逻辑，不需要从源对象赋值。比如VO里的statusDesc字段，运行时通过字段初始值或者default方法计算，不需要从源对象映射。加上@Mapping(ignore = true)即可。

有些开发者喜欢全局关闭这个报错，设置unmappedTargetPolicy = ReportingPolicy.IGNORE。我不建议这样做，因为这会同时关闭真正有用的错误检查。漏字段的转换，编译期发现远好于运行期测试发现。团队里如果新人比较多，保持默认的报错策略，能强制大家把映射关系写清楚。

6.2 字段类型不一致的处理思路

源字段是Long，目标字段是Integer，或者源字段是String，目标字段是LocalDate，MapStruct编译时会报无法自动转换的错或警告。这时候有几种处理方式。

如果是日期类型和字符串之间的转换，用@Mapping的dateFormat指定。

如果是数值类型之间的转换，比如Long转Integer，MapStruct大多数情况可以直接转，但如果超出了Integer范围会有运行时风险。我一般会在default方法里做显式转换加校验：

default Integer safeLongToInt(Long value) { if (value == null) { return null; } if (value > Integer.MAX_VALUE || value < Integer.MIN_VALUE) { throw new IllegalArgumentException("数字超出范围"); } return value.intValue(); }

自定义转换器与default方法的选择，看转换逻辑的复杂度。一行表达式能搞定的用expression，有多行逻辑的用default方法，涉及外部服务调用或Spring Bean的用default方法里注入。

6.3 嵌套对象为null时的空指针隐患

MapStruct对单层映射生成的代码会判空，但嵌套映射的处理需要额外注意。假设这样一个场景：

@Mapping(target = "cityName", source = "user.address.city.name") OrderVO toVO(Order order);

如果order.getUser()为null，MapStruct生成的代码会返回null，不会抛NPE。但如果user不为null而address为null，生成的代码依然能稳妥处理。实测了1.6.3版本，多层路径无论是哪一层为空，生成的代码都能安全返回null。这个点比手写代码可靠得多，手写时特别容易漏掉中间对象的判空。

但要注意，如果目标对象是集合类，比如setUserAddresses(List

6.4 性能实测与高并发场景表现

不纸上谈兵，我拿一个实际订单模块做了一组简单对比。同一份Order列表，1000个对象转VO，手写getter/setter约耗时几十毫秒，MapStruct生成的实现类约耗时相同量级，因为它在编译期已经生成了直接方法调用。Spring BeanUtils反射拷贝在同样条件下耗时大约为手写的5到8倍，在1000次转换的压力下差距非常明显。更直观的测试是在一个QPS较高的接口上，整体TPS提升了大约3%到5%。

这个数据不严谨，但方向可以说明问题。反射方案在低并发低数据量下可能感觉不到差异，但对象转换是高频操作，一个接口里有可能出现多次转换，累积效应在压测时就体现出来了。

曾有个金融类项目，改造前所有DTO转Entity都用Spring的BeanUtils，压测时发现转换操作占了接口整体耗时的8%左右，改造为MapStruct后，这个比例降到了1%以内。这笔账算下来，迁移成本基本可以忽略，收益是实实在在的。

6.5 常用排查命令与编译日志技巧

排查MapStruct问题，第一件事是看生成的实现类。Maven项目编译后，在target/generated-sources/annotations路径下能找到同名Impl文件，打开看就能知道映射逻辑是否按预期生成。这个方法比反复猜测有效得多。

IDEA中可以通过Build菜单重新编译项目，然后在Project视图里找到generated-sources/annotations文件夹，展开对应的包名，直接查看UserMapperImpl代码。

如果编译报错信息不够详细，可以打开Maven编译的详细日志：

mvn clean compile -Dmaven.compiler.showWarnings=true

MapStruct在编译期会产生一些warning信息，默认被隐藏。打开showWarnings后，很多配置不当引起的隐患会提前暴露，比如字段名拼写错误导致自动忽略某些映射，日志中会有提示。

调试的时候断点打在生成的Impl方法上，和打在手写转换方法上一样顺畅。IDE能正常Step Into，因为实现类就是普通的Java类，没有任何代理和反射包装。

最后聊两句体感

对象映射这件事，看着小，但每天都在做。从一个偏执于手写转换的团队过渡到MapStruct，前后大概花了几天适应，之后就再也不想回去手写getter/setter了。最直观的改变不是代码行数少了多少，而是改字段不再心惊胆战，编译器会帮我们兜住漏映射的底。如果你正处在新项目选型或者老项目改造的阶段，我给的建议是：把MapStruct作为默认方案先跑起来，字段不多时可能感受不到差异，一旦字段超过十个，差异就是天壤之别。有同事问是不是所有转换都要用MapStruct，我的看法是，涉及DTO、VO、Entity之间的映射，交给它就很合适；如果只是两个内部工具类之间的一次性简单转换，手写几行也没问题，工具是帮我们省力的，不是让我们为了用而用。