在使用Spring Boot构建微服务应用时，我们经常需要通过WebClient进行RESTful API调用。当尝试将一个由Spring管理的、特别是被增强过的Bean（如通过`@ConfigurationProperties`注解配置的Bean）直接作为请求体发送时，可能会遇到序列化异常。本文将深入分析这一问题，并提供两种解决方案，包括一种实用的规避方案和一种更符合最佳实践的推荐方法。
理解问题：Spring Bean与WebClient序列化挑战
在某些场景下，为了避免重复创建请求对象，开发者可能希望直接使用一个已配置好的Spring Bean作为REST请求的JSON体。例如，一个通过@ConfigurationProperties注解管理的配置Bean，其结构如下：
@ConfigurationProperties(prefix = "myprefix")
@Configuration("configname")
@Getter
@Setter
public class ConfigDetails {
private String c1;
private String c2;
private String c3;
}当尝试使用WebClient将此ConfigDetails Bean发送出去时，代码可能类似于：
// configDetails 是通过 @Autowired 注入的 ConfigDetails 实例 webClient.post().body(Mono.just(configDetails), ConfigDetails.class).retrieve().bodyToMono(String.class).block();
然而，在序列化过程中，通常会遇到类似以下堆栈跟踪的错误：
No serializer found for class org.springframework.context.expression.StandardBeanExpressionResolver and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: com.example.ConfigDetails$$EnhancerBySpringCGLIB$$cad0a6e6["$$beanFactory"]->org.springframework.beans.factory.support.DefaultListableBeanFactory["beanExpressionResolver"])
分析根本原因
这个错误信息揭示了问题的核心：ConfigDetails$$EnhancerBySpringCGLIB$$cad0a6e6。这表明Spring在运行时对ConfigDetails Bean进行了增强，通常是通过CGLIB库创建了一个代理子类。这种增强是为了实现Spring的AOP（面向切面编程）功能、代理作用域或处理@Configuration类中的@Bean方法等。
被CGLIB增强的Bean实例，除了我们定义的业务属性（如c1, c2, c3）外，还会包含一些Spring框架内部使用的属性，例如$$beanFactory、$$beanName等。当Jackson等JSON序列化库尝试序列化这些增强过的Bean时，它会遍历所有属性。对于这些Spring内部的属性，Jackson找不到对应的序列化器，也无法将其识别为普通的Java Bean属性，从而抛出No serializer found的异常。
解决方案一：创建静态非增强副本 (Workaround)
一种直接的规避方法是在被增强的Bean内部维护一个其自身属性的“纯净”副本。这个副本不会被Spring增强，因此在序列化时不会携带额外的Spring内部属性。
具体实现步骤如下：
- 在ConfigDetails类中添加一个静态变量来持有非增强的副本。
- 使用@PostConstruct注解的方法在Bean初始化后，将当前实例的业务属性复制到静态副本中。
- 提供一个静态方法来获取这个非增强的副本。
修改后的ConfigDetails类如下：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;
import javax.annotation.PostConstruct;
import lombok.Getter;
import lombok.Setter;
@ConfigurationProperties(prefix = "myprefix")
@Configuration("configname")
@Getter
@Setter
public class ConfigDetails {
private String c1;
private String c2;
private String c3;
// 静态变量，用于保存非增强的ConfigDetails副本
private static ConfigDetails staticConfigDetailsInstance;
@PostConstruct
public void init(){
// 在Bean初始化后，将当前实例的属性复制到静态副本
staticConfigDetailsInstance = new ConfigDetails();
staticConfigDetailsInstance.setC1(this.c1);
staticConfigDetailsInstance.setC2(this.c2);
staticConfigDetailsInstance.setC3(this.c3);
// 如果有其他属性，也需要在此处进行复制
}
// 提供静态方法获取非增强的副本
public static ConfigDetails getInstance(){
return staticConfigDetailsInstance;
}
}现在，在WebClient调用时，不再直接使用注入的configDetails实例，而是使用其静态副本：
// 使用静态方法获取非增强的实例进行序列化
webClient.post()
.body(Mono.just(ConfigDetails.getInstance()), ConfigDetails.class)
.retrieve()
.bodyToMono(String.class)
.block();此方案的优缺点：
- 优点： 有效解决了序列化问题，实现简单直接。
-
缺点：
- 引入了手动属性复制的环节，如果ConfigDetails的属性发生变化，需要同步更新init()方法，增加了维护成本和出错的可能性。
- 静态实例的生命周期与应用相同，如果ConfigDetails的属性在运行时可能动态变化，这种方式可能无法及时反映最新状态（尽管@ConfigurationProperties通常是静态配置）。
解决方案二：推荐的实践 - 使用数据传输对象 (DTO)
更符合软件工程最佳实践的方法是使用数据传输对象（DTO）。DTO是专门为数据传输设计的简单Java对象，它不包含任何业务逻辑，也不会被Spring增强。通过DTO，我们可以将内部的配置Bean与外部API的契约解耦。
实现步骤：
- 创建一个简单的POJO作为DTO，包含需要发送给API的属性。
- 在发送请求前，将ConfigDetails Bean的属性映射到DTO实例。
// 1. 定义一个简单的DTO类
@Getter
@Setter
@NoArgsConstructor // 需要无参构造函数以供Jackson使用
@AllArgsConstructor // 方便构造
public class ConfigRequestDTO {
private String c1;
private String c2;
private String c3;
}- 在调用WebClient前进行映射：
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;
@Service
public class MyApiService {
private final WebClient webClient;
private final ConfigDetails configDetails; // 注入原始的ConfigDetails Bean
@Autowired
public MyApiService(WebClient webClient, ConfigDetails configDetails) {
this.webClient = webClient;
this.configDetails = configDetails;
}
public String sendConfigToApi() {
// 2. 将ConfigDetails的属性映射到ConfigRequestDTO
ConfigRequestDTO requestDTO = new ConfigRequestDTO(
configDetails.getC1(),
configDetails.getC2(),
configDetails.getC3()
);
// 3. 使用DTO作为WebClient的请求体
return webClient.post()
.uri("/api/endpoint") // 替换为实际的API路径
.body(Mono.just(requestDTO), ConfigRequestDTO.class)
.retrieve()
.bodyToMono(String.class)
.block();
}
}此方案的优缺点：
-
优点：
- 解耦： 将内部实现细节（ConfigDetails作为Spring Bean）与外部API契约（ConfigRequestDTO）分离。
- 清晰的API契约： DTO明确定义了API期望的数据结构，易于理解和维护。
- 避免序列化问题： DTO是纯粹的POJO，不会被Spring增强，因此不会有内部属性导致序列化失败。
- 灵活性： 可以在DTO中添加或移除字段，而不会影响ConfigDetails的内部结构。
- 缺点： 引入了一个额外的类和映射步骤，对于非常简单的场景可能显得有些繁琐（但通常是值得的）。
总结与最佳实践
当Spring Bean（特别是被CGLIB增强的Bean）作为WebClient请求体进行序列化时，由于其包含Spring内部属性，可能导致序列化失败。
静态非增强副本是一种快速解决问题的规避方案。它通过在Bean内部创建一个纯净的静态副本进行序列化。此方法适用于配置Bean属性相对稳定且不频繁变动的场景，但需注意手动维护属性复制的风险。
使用数据传输对象（DTO）是更推荐的最佳实践。它通过引入一个专门用于API通信的POJO来解耦内部Bean和外部API契约。DTO模式不仅解决了序列化问题，还提高了代码的可维护性、可读性和API契约的清晰度，是构建健壮微服务应用的优选方案。
在实际开发中，我们应优先考虑使用DTO模式，以确保API接口的稳定性和代码的健壮性。只有在极度追求简洁且明确知晓风险的情况下，才可考虑静态非增强副本的规避方案。
