接收RabbitMQ消息时遇'scopedTarget.get' Bean创建错误：请求作用域适配问题

我之前处理过类似的问题，核心矛盾很清晰：RabbitMQ的消费线程完全独立于HTTP请求上下文，没法直接获取@Scope("request")的Bean。下面给你几个实用的解决方案，按推荐程度排序：

1. 自定义Envers审计用户提供者（最优解） #

Hibernate Envers本身支持通过AuditAware接口自定义审计用户的获取逻辑，这能从根源上适配请求和消息消费两种场景：

@Component
public class CustomAuditAware implements AuditAware<String> {

    @Override
    public Optional<String> getCurrentAuditor() {
        // 先检查是否处于HTTP请求上下文
        RequestAttributes requestAttrs = RequestContextHolder.getRequestAttributes();
        if (requestAttrs != null) {
            // 从请求上下文获取用户（比如Spring Security的认证信息）
            Authentication auth = SecurityContextHolder.getContext().getAuthentication();
            return Optional.ofNullable(auth != null ? auth.getName() : null);
        } else {
            // 从RabbitMQ消息中提取用户信息
            // 这里需要根据你的消息结构调整，比如从消息头或消息体读取
            Message<?> currentMessage = MessageContext.getCurrentMessage();
            String userId = (String) currentMessage.getHeaders().get("audit-user-id");
            return Optional.ofNullable(userId);
        }
    }
}

这样不管是在Rest Controller的请求场景，还是RabbitMQ的消费场景，Envers都能正确拿到审计用户，完全不需要依赖@Scope("request")的Bean。

2. 剥离request作用域依赖，单独处理消息场景 #

如果你的User Bean是专门为请求场景设计的，那在消息消费场景下直接复用它本来就不合理。可以把用户信息的获取逻辑抽离：

• 在Rest Controller中，依然从request作用域获取用户；
• 在RabbitMQ消费方法中，直接从消息体/消息头提取用户标识，然后构造或查询出需要的用户信息，传递给后续的数据库操作。

这种方式更清晰，避免了跨场景的Bean依赖问题，代码的可读性和维护性更好。

3. 手动模拟请求上下文（应急方案，不推荐） #

如果暂时没法重构代码，只能硬着头皮用@Scope("request")的Bean，可以手动在消费线程中创建一个模拟的请求上下文：

@RabbitListener(queues = "your-queue")
public void handleMessage(YourMessage message) {
    // 创建模拟请求上下文
    RequestAttributes mockRequestAttrs = new ServletRequestAttributes(new MockHttpServletRequest());
    RequestContextHolder.setRequestAttributes(mockRequestAttrs);

    try {
        // 执行你的数据库操作和Envers逻辑
        yourService.saveEntity(convertToEntity(message));
    } finally {
        // 务必清理上下文，避免线程污染
        RequestContextHolder.resetRequestAttributes();
    }
}

⚠️ 注意：这只是临时的应急手段，因为模拟的请求上下文没有真实请求的属性（比如Session、请求头），如果你的User Bean依赖这些属性，依然会报错。而且这种方式违背了Spring作用域的设计初衷，长期来看容易引发隐藏问题。

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