MapStruct Mapper设计中的分类划分标准是什么

首先明确：MapStruct 框架本身没有强制要求「一个DTO/Entity必须对应一个独立Mapper」，你提到的两种写法都不属于语法或设计层面的错误，选择哪种方案核心看业务边界和后续维护成本，不需要死套教条式规范。

同个Mapper中放多个转换方法的适用场景 #

如果你的场景符合以下特征，完全可以把两个转换方法都写在UserMapper里，这是非常常见的合理写法：

• 两个DTO都属于用户业务域，转换的根实体都是UserEntity
• 转换逻辑简单，没有大量复杂的字段映射、关联对象查询、自定义转换逻辑
• 两个DTO的迭代节奏基本一致，归属同一个开发团队维护

示例写法如下：

@Mapper
public interface UserMapper {
    // 转用户基础信息DTO
    UserInfoDTO toUserInfoDTO(UserEntity entity);
    // 转用户统计信息DTO
    UserCountDTO toUserCountDTO(UserEntity entity);
}

这种写法的优势很明显：同领域的转换逻辑聚合在同一个类里，不需要创建大量零散的Mapper文件，查找和修改相关逻辑的效率更高，也符合领域驱动设计中按聚合根组织代码的思路，完全不属于错误设计。

需要拆分独立Mapper的适用场景 #

如果出现以下情况，拆分为UserInfoMapper、UserCountMapper两个独立类才是更优选择：

• 两个DTO的转换逻辑复杂度差异极大：比如UserCountDTO只需要映射3个统计字段，逻辑非常简单，但UserInfoDTO需要关联映射角色、部门、权限等多类关联对象，需要写大量@Mapping规则、自定义默认方法、甚至注入多个其他Service/辅助Mapper，此时所有逻辑塞在同一个类里会导致文件快速臃肿，修改某一个转换逻辑时容易误影响另一个
• 两个DTO归属的业务边界完全独立：比如UserInfoDTO是用户中心模块内部使用的对象，UserCountDTO是提供给数据统计模块的跨模块传输对象，拆分后不同模块的需求变更只需要修改对应Mapper，不会出现“改统计字段碰坏用户基础信息转换”的耦合问题
• 团队协作有明确的权限边界：比如两个DTO分别由两个独立的开发团队维护，拆分Mapper可以避免代码提交权限的交叉，减少协作成本

核心判断原则：要不要拆分的依据从来不是“有多少个DTO”，而是这些转换逻辑是否同属一个业务边界、后续是否会独立演进、放在一起会不会提升维护成本。不要为了凑“单一职责”的表面规范强行拆分，那种每个Mapper里只有一个简单转换方法、全项目零散着上百个Mapper的结构，反而比合理聚合的结构难维护得多。

内容的提问来源于stack exchange，提问作者바보린