Spring R2DBC EntityCallbacks与Mapping的区别及多租户场景选型咨询

一、两者核心差异 #

1. 定位和职责 #

• R2DBC Mapping：负责数据库行与实体类之间的基础字段映射，比如将实体的tenantId属性对应到库表的tenant_id列，处理类型转换、命名规则转换这类基础工作，本质是数据转换工具。
• EntityCallbacks：是实体生命周期的扩展钩子，可在实体保存前、更新前、加载后等节点插入自定义逻辑，不负责基础映射，专门用来干预实体的生命周期行为。

2. 触发逻辑 #

• R2DBC Mapping是被动触发的，只要执行CRUD操作，它就会自动完成数据的序列化/反序列化，属于持久化流程的必备环节。
• EntityCallbacks需要手动注册对应实现（比如BeforeSaveCallback），才会在指定节点执行自定义代码，是主动扩展的机制。

3. 扩展边界 #

• R2DBC Mapping的扩展仅围绕映射规则，比如自定义类型转换器，但无法完成给实体赋值业务属性这类操作。
• EntityCallbacks可针对不同实体、不同生命周期阶段编写逻辑，灵活性更高，完全独立于映射逻辑。

二、多租户场景下选哪个？ #

就你描述的「Web过滤器将TenantId存入请求上下文，数据库调用前赋值」场景，EntityCallbacks是更能实现解耦的方案，理由如下：

• 业务代码彻底无需关心TenantId：业务层只需保证实体包含tenantId字段，从上下文获取TenantId、给实体赋值的操作全封装在回调中，业务代码完全感知不到这一步。
• 职责划分清晰：Mapping负责字段映射，回调负责租户标识注入，不会将映射逻辑与业务属性赋值混在一起，符合单一职责原则。
• 需求变更成本低：后续若TenantId的获取方式改变（比如从Header改为从Token中提取），只需修改回调实现，无需改动业务代码；甚至可为不同实体配置不同的TenantId注入规则。

简单示例代码 #

注册BeforeSave回调

@Component
public class TenantIdInjectCallback implements BeforeSaveCallback<BaseTenantEntity> {

    @Override
    public Object onBeforeSave(BaseTenantEntity entity, MutableAggregateChange<BaseTenantEntity> change, SqlIdentifier table) {
        // 从请求上下文获取TenantId
        String tenantId = RequestContextHolder.getCurrentTenantId();
        entity.setTenantId(tenantId);
        return entity;
    }
}

基础租户实体

public abstract class BaseTenantEntity {
    private String tenantId;
    // getter、setter
}

业务实体只需继承该基类，无需处理TenantId相关逻辑，回调会自动在保存前完成注入。

三、为什么不选R2DBC Mapping？ #

若强行用Mapping处理TenantId，需自定义转换器或修改映射规则，这会将业务属性赋值逻辑混入映射层，打乱职责划分。而且Mapping层本身无法直接获取Web请求上下文，还需额外编写上下文传递代码，反而增加耦合，完全没必要。

内容的提问来源于stack exchange，提问作者George Jose