MapStruct 这行『高级用法』,让下游服务被重复调用了三遍

MapStruct 的 uses + qualifiedBy,是怎么把一次映射变成多次下游调用的

写在前面:一个"看着优雅、实则埋雷"的现场

上一篇聊对象映射三件套时,结尾埋了个钩子。这篇拆一个我在另一个项目里真实遇到的反模式——它长得像 MapStruct 的"高级用法",代码规范、注释齐全,却在线上悄悄把同一个下游调了不止一遍。

先看几行关键代码,你能一眼看出问题吗?

@Mapper(componentModel = "spring",
        uses = {AccountConfigService.class, MemberService.class})
public interface OrderMapper {

    @Mapping(target = "sourceAccountId", source = "paramExtend",
             qualifiedBy = AccountConfigService.ResolveSourceAccount.class)
    @Mapping(target = "protocolAccountId", source = "paramExtend",
             qualifiedBy = MemberService.ResolveProtocolAccount.class)
    OrderEntity toEntity(OrderDo order, ParamExtend paramExtend);
}

两个字段的值,都由 qualifiedBy 指定的外部方法算出来。问题恰恰藏在这份"干净"里。

一、为什么翻车:每个 @Mapping 独立生成调用

MapStruct 是编译期代码生成器,它对每一个 @Mapping 独立生成一行 setter 调用——不去重、不缓存、不共享上下文。上面那段代码,生成出来大致长这样:

public OrderEntity toEntity(OrderDo order, ParamExtend paramExtend) {
    OrderEntity e = new OrderEntity();
    e.setSourceAccountId(accountConfigService.resolveSourceAccount(paramExtend));   // 第 1 次
    e.setProtocolAccountId(memberService.resolveProtocolAccount(paramExtend));     // 第 2 次
    return e;
}

如果这两个方法只是"算一下、不碰外部",独立调用毫无问题。但追进去看,问题就露出来了。

二、追进去看:两条链路打的是同一个下游

resolveSourceAccount 内部,最终调的是 queryAccountViaChannel(...) 或 queryAccountViaFallback(bizNo);而 resolveProtocolAccount 内部,调的也是这两个方法。

也就是说,两条链路打的是同一个下游账户服务、同一组参数、返回同一个值。但 MapStruct 不知道这一点——它只会忠实执行"每个字段各调一次":

场景	下游接口	实际调用次数
协议场景 + 走渠道侧查询	queryAccountViaChannel(HTTP)	2 次
协议场景 + 走兜底查询	queryAccountViaFallback(RPC)	2 次

 

 

DB 查询也一样重:loadSceneConfig(...) 内部是同一条 queryByCondition(...),在同一次映射里最多被调 3 次——sourcePurpose 一次、targetPurpose 一次、sourceAccountId 一次。

诚实补一句:这些触发条件不完全相同,靠 businessType / channelScene 分支,所以不是每次都真重复;但风险结构确实存在。

 

三、这还不是最坏的部分:系统性副作用

uses 里堆了一堆 Service 之后,副作用是系统性的,挑几个最要命的:

1. 重复 / N+1 下游调用——多个字段各自独立查,没有共享上下文,最直接的成本;

2. 隐式耦合,可读性塌陷——读 Mapper 接口根本看不出"这个字段是查库/RPC 算出来的",DTO 转换本该是纯字段搬运,现在悄悄混进了业务查询;

3. 事务被拖长——qualifier 里的 RPC/DB 查询发生在映射时刻,若映射在事务内,等于把远端调用和长查询塞进事务,占连接、延长锁持有时间;

4. 责任错配 / 逻辑漂移——AccountConfigService 和 MemberService 各写一套"如何取协议账户",分支判断几乎一样;一旦两边演进不同步,同一个字段可能出现两种结果。

 

四、怎么改:把"查一次、复用结果"提到调用方

核心思路一句话:让 Mapper 只做纯字段搬运,不查数据;查一次、复用结果这件事,放到调用方去做。

最简单的做法,是在 Service 层先查一次,把结果作为参数传给 Mapper:

// Service 层:先查一次,复用结果
String sourceAccountId = accountConfigService.resolveSourceAccount(paramExtend);
String protocolAccountId = memberService.resolveProtocolAccount(paramExtend);

// Mapper:只搬字段,不查任何东西
OrderEntity toEntity(OrderDo order, ParamExtend paramExtend,
                     String sourceAccountId, String protocolAccountId);

参数一多,可以换成 @Context 传一个预取好结果的上下文对象,qualifier 只从上下文里取现成值。但无论哪种,原则都一样:下游只被调一次,而不是每个字段一次。

更进一步,如果 AccountConfigService 和 MemberService 那两套"取协议账户"的逻辑几乎一样,治本的做法是把它统一收口到一个 Manager,两个字段都从同一个方法取——既去重,又消灭逻辑漂移。

五、总结

先给个定性:这是设计层面的翻车,不是工具翻车。 MapStruct 的类型安全、编译期生成这些优势都没毛病;翻车的是"把带副作用的下游查询塞进 qualifiedBy 映射"这个模式——它让重复调用、隐式耦合、责任错配同时出现,是典型的反模式。

回到那句老话:映射管形状,业务管语义。

MapStruct 再好,它也只是"编排调用"的工具——你声明了哪个字段走哪个方法,它就忠实执行,不会替你判断"这两次调用是不是同一件事"。去重,不是映射库的责任,是调用方的责任。

所以下次你在 @Mapper 的 uses 里塞 Service、在 @Mapping 里写 qualifiedBy 时,先问自己一句:这个 qualifier,会去查库、调 RPC 吗? 会的话,把它提到调用方,查一次、传进来。

写在最后:聊聊你的翻车

你有没有在 MapStruct(或 Orika、BeanUtils)上踩过类似的坑?比如 qualifiedBy 查库导致 N+1、uses 里成环启动报错、或者调了半天才发现某个字段是查出来的?欢迎在评论区聊聊——你是怎么发现、又怎么定位和解决的?

 

本文首发于公众号：[习惯沉淀]，转载请注明出处。