深入解析Spring中的@Configuration与@Bean：Full模式与Lite模式的源码级对比

用户6320865

发布于 2025-08-27 16:56:41

8800

代码可运行

运行总次数：0

代码可运行

Spring配置类简介

在Spring框架的演进历程中，基于Java的配置方式逐渐取代了传统的XML配置成为主流方案。这种转变的核心支撑正是@Configuration和@Bean这对黄金组合，它们构成了现代Spring应用配置的基石。

配置类的革命性意义

传统Spring应用需要编写冗长的XML文件来定义Bean及其依赖关系，而@Configuration注解的出现彻底改变了这一局面。这个标注在类上的注解向Spring容器宣告：这是一个配置类，包含着一个或多个@Bean注解的方法，这些方法将负责创建和配置应用中的对象。

与XML配置相比，基于Java的配置具有显著优势：

强类型检查：编译器能在编码阶段发现类型错误
更好的重构支持：IDE可以智能追踪方法引用
更灵活的配置逻辑：可以直接使用Java语言特性实现复杂配置
配置集中化：相关配置可以按功能模块组织在一起

@Configuration的核心机制

当一个类被标注为@Configuration时，Spring容器会对其进行特殊处理。在底层实现上，配置类会经过ConfigurationClassPostProcessor这个后置处理器的处理，该处理器会解析配置类中的所有@Bean方法，并将这些方法转换为Spring容器中的Bean定义。

值得注意的是，@Configuration类本身也会被注册为Spring容器中的一个Bean。这意味着配置类可以像普通Bean一样被注入到其他组件中，也可以实现AOP拦截等特性。

@Bean方法的本质

@Bean注解用于标注在配置类的方法上，指示该方法将返回一个对象，该对象应该被注册为Spring应用上下文中的Bean。每个@Bean方法本质上都是一个工厂方法，Spring容器会调用这些方法来创建对应的Bean实例。

与XML中<bean>标签定义的Bean类似，@Bean方法也支持：

指定初始化/销毁方法（通过initMethod和destroyMethod属性）
设置Bean的作用域（通过@Scope注解配合）
声明Bean的依赖关系（通过方法参数自动装配）

配置类的典型结构

一个完整的配置类通常包含以下要素：

@Configuration
public class AppConfig {
    
    @Bean
    @Scope("prototype")
    public ServiceA serviceA(Repository repository) {
        return new ServiceAImpl(repository);
    }
    
    @Bean(initMethod = "init")
    public Repository repository() {
        return new JdbcRepository(dataSource());
    }
    
    @Bean
    @Lazy
    public DataSource dataSource() {
        // 创建并配置数据源
    }
}

在这个示例中，我们可以看到：

@Configuration标注在类级别，声明这是一个配置类
每个@Bean方法对应一个Spring Bean的定义
Bean之间的依赖通过方法参数或方法调用表达
可以使用@Scope、@Lazy等注解调整Bean特性

配置类的加载方式

在Spring应用中，配置类可以通过多种方式加载：

在传统Spring应用中通过AnnotationConfigApplicationContext显式注册：

ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);

在Spring Boot应用中通过@ComponentScan自动扫描

作为@Import的目标被其他配置类引入

在测试环境中通过@ContextConfiguration指定

这种加载方式的灵活性使得配置类可以很好地适应各种应用场景，从简单的单元测试到复杂的生产环境部署。

配置类的进阶特性

除了基本的Bean定义功能外，配置类还支持一些高级特性：

条件化配置：通过@Conditional系列注解实现条件化Bean注册
配置类组合：使用@Import引入其他配置类
环境适配：结合@Profile实现不同环境的不同配置
配置属性绑定：与@ConfigurationProperties配合实现外部化配置

这些特性使得基于Java的配置方式不仅能够替代XML配置，还能实现更加灵活和强大的配置逻辑。

Full模式与Lite模式概述

在Spring框架中，@Configuration注解的类支持两种截然不同的工作模式：Full模式（完整模式）和Lite模式（轻量模式）。这两种模式的核心差异体现在Bean方法的调用行为、运行时性能开销以及适用场景上，理解它们的区别对于编写高效、符合预期的Spring配置至关重要。

两种模式的基本定义

Full模式是@Configuration注解的默认工作方式，通过设置@Configuration(proxyBeanMethods = true)显式启用。该模式下，Spring会使用CGLIB对配置类进行字节码增强，生成一个运行时代理子类。这种增强带来的关键特性是：当配置类中的一个@Bean方法调用另一个@Bean方法时，Spring会确保每次调用都返回容器中的单例实例，而不是简单执行方法体创建新对象。

Lite模式则需要通过@Configuration(proxyBeanMethods = false)显式声明。在这种模式下，配置类不会被CGLIB增强，所有@Bean方法都作为普通工厂方法处理。当方法间相互调用时，会直接执行方法体逻辑，可能产生多个实例，这与常规Java方法调用行为一致。

行为差异的典型示例

考虑以下配置类：

@Configuration
public class AppConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB());
    }
    
    @Bean 
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

在Full模式下，serviceA()中对serviceB()的调用会被拦截，Spring会返回容器中已存在的ServiceB实例。而在Lite模式下，这会导致每次调用都创建一个新的ServiceB实例，可能造成非预期的对象增殖。

底层实现机制

Full模式的魔法源自ConfigurationClassEnhancer这个CGLIB增强器。它会在运行时生成配置类的子类，重写所有@Bean方法，加入以下逻辑：

检查当前Bean是否已存在于容器中
如果存在则直接返回容器中的实例
不存在时才执行原始方法逻辑
将新创建的Bean注册到容器

这种增强通过BeanMethodInterceptor拦截器实现，其核心逻辑可以在ConfigurationClassEnhancer的源码中观察到：

private static class BeanMethodInterceptor implements MethodInterceptor {
    public Object intercept(Object enhancedConfigInstance, Method method, Object[] args, MethodProxy methodProxy) {
        // 检查容器中是否已有该Bean
        if (isCurrentlyInvokedFactoryMethod(method)) {
            return methodProxy.invokeSuper(enhancedConfigInstance, args);
        }
        return resolveBeanReference(method, args, enhancedConfigInstance);
    }
}

相比之下，Lite模式完全跳过了这个增强过程。ConfigurationClassPostProcessor在处理配置类时，会通过ConfigurationClassUtils检查proxyBeanMethods属性，决定是否需要进行CGLIB增强。

性能与使用场景对比

Full模式由于需要运行时字节码增强和额外的方法拦截，会带来一定的性能开销。根据Spring官方测试，启动时间可能增加10-20%。但这种开销换来了以下优势：

确保Bean依赖关系的正确性
支持复杂的Bean初始化逻辑
便于实现条件化配置（如与@Conditional配合使用）

Lite模式则更适合以下场景：

对启动性能有严格要求的应用
配置类中没有Bean方法间的相互调用
使用@Component等注解替代@Configuration的简单场景
需要与GraalVM原生镜像编译配合的情况（因为CGLIB增强不兼容AOT）

模式选择的实践建议

在实际开发中，选择模式需要考虑以下因素：

依赖关系复杂度：当配置类中存在Bean方法间的交叉调用时，必须使用Full模式
启动时间敏感度：微服务冷启动要求高的场景可评估使用Lite模式
测试便利性：Lite模式由于没有代理，单元测试时更易理解和mock
框架兼容性：某些Spring生态组件（如Spring Cloud）可能依赖Full模式特性

Spring Boot在自动配置类中大量使用Lite模式，正是因为自动配置类通常设计为相互独立，不需要方法间调用。这种设计选择显著提升了Spring Boot应用的启动速度。

源码解析：ConfigurationClassPostProcessor

在Spring框架的核心机制中，ConfigurationClassPostProcessor扮演着配置类处理的"总调度员"角色。作为BeanDefinitionRegistryPostProcessor接口的唯一Spring官方实现（根据Spring 5.0.6源码），它在容器启动阶段通过复杂的处理逻辑，将普通的Java类转化为Spring容器可识别的配置单元。

启动阶段的处理入口

当AbstractApplicationContext执行refresh()方法时，在第五个关键步骤会触发postProcessBeanDefinitionRegistry方法的调用。这个方法接收BeanDefinitionRegistry作为参数，通过System.identityHashCode生成唯一的registryId来确保每个配置注册表的处理只会执行一次。这种设计避免了在复杂应用场景下可能出现的重复处理问题，体现了Spring框架对稳定性的极致追求。

配置类识别的核心逻辑

该处理器通过双重检测机制确保处理过程的幂等性：首先检查registriesPostProcessed集合是否包含当前registryId，然后验证factoriesPostProcessed集合的状态。这种严谨的防御性编程使得Spring能够应对各种复杂的容器初始化场景。

在处理过程中，ConfigurationClassPostProcessor会创建ConfigurationClassParser实例来执行实际的配置类解析工作。这个解析器采用"种子配置类"的概念，从显式注册的配置类出发，通过递归分析@Import注解、嵌套类等元数据，构建完整的配置类图谱。值得注意的是，解析过程中会特别关注@Configuration注解的preserveTargetClass属性，这直接关系到后续是否启用CGLIB增强。

配置类增强的预处理

在完成配置类识别后，处理器会通过ConfigurationClassUtils检查每个候选类的元数据，关键步骤包括：

使用checkConfigurationClassCandidate方法评估类是否具备配置类资格
解析@Configuration注解的proxyBeanMethods属性（默认为true）
在BeanDefinition中设置CONFIGURATION_CLASS_ATTRIBUTE属性，标记为"full"或"lite"模式

这些预处理操作为后续的增强阶段奠定了重要基础。特别是在Spring 5.2之后引入的显式proxyBeanMethods控制，使得开发者可以更精细地调整配置类的行为模式。

后处理阶段的增强触发

在postProcessBeanFactory方法中，处理器会执行关键的增强操作：

public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
    // 生成唯一ID防止重复处理
    int factoryId = System.identityHashCode(beanFactory);
    if (this.factoriesPostProcessed.contains(factoryId)) {
        throw new IllegalStateException(
            "postProcessBeanFactory already called on this post-processor against " + beanFactory);
    }
    this.factoriesPostProcessed.add(factoryId);
    
    // 执行实际的增强逻辑
    enhanceConfigurationClasses(beanFactory);
}

其中enhanceConfigurationClasses方法会筛选出标记为full模式的配置类，通过ConfigurationClassEnhancer进行CGLIB代理增强。这个增强过程会为配置类添加三个关键能力：

Bean方法拦截（确保@Bean方法间的调用走容器逻辑）
BeanFactory感知（实现EnhancedConfiguration接口）
作用域代理支持（用于@Scope注解的处理）

元数据处理的关键细节

处理器内部维护了两个重要集合registriesPostProcessed和factoriesPostProcessed，采用WeakHashMap实现以避免内存泄漏。这种设计展现了Spring框架在资源管理方面的精细考量，特别是在处理可能被垃圾回收的临时对象时。

在处理@Bean方法时，处理器会通过ConfigurationClassBeanDefinitionReader将每个@Bean方法转化为特殊的BeanDefinition。这些定义会携带factoryBeanName和factoryMethodName等元数据，使得Spring容器能够正确识别并处理配置类中的工厂方法。这种转换过程充分考虑了方法参数、返回类型等细节，确保了依赖注入的准确性。

模式选择的内部机制

ConfigurationClassPostProcessor通过分析配置类的元数据决定处理策略：

对于显式标注@Configuration且未设置proxyBeanMethods=false的类，采用full模式
对于@Component、@ComponentScan等注解标注的类，采用lite模式
对于@Bean方法直接标注的类，同样采用lite模式

这种区分在processConfigBeanDefinitions方法中表现得尤为明显，其中会构建专门的ConfigurationClass对象来承载不同的处理策略。值得关注的是，从Spring 5.2开始，开发者可以通过@Configuration(proxyBeanMethods=false)显式选择lite模式，这为配置类的使用提供了更大的灵活性。

源码解析：ConfigurationClassEnhancer

在Spring框架的配置类处理机制中，ConfigurationClassEnhancer是实现Full模式魔法的核心引擎。这个位于org.springframework.context.annotation包下的工具类，通过CGLIB字节码增强技术，为@Configuration类创建动态子类，赋予其管理Bean依赖关系的超能力。

ConfigurationClassEnhancer通过CGLIB增强@Configuration类的工作流程图

CGLIB增强的实现机制

当Spring容器启动时，ConfigurationClassPostProcessor会调用ConfigurationClassEnhancer.enhance()方法对Full模式的配置类进行增强。该方法的精妙之处在于创建了一个包含特殊回调的CGLIB代理：

private static final Callback[] CALLBACKS = new Callback[] {
    new BeanMethodInterceptor(),  // 处理@Bean方法调用的核心拦截器
    new BeanFactoryAwareMethodInterceptor(),  // 处理BeanFactoryAware接口
    NoOp.INSTANCE  // 默认回调
};

其中BeanMethodInterceptor是实现Full模式特性的关键。当增强后的配置类方法被调用时，这个拦截器会首先检查当前方法是否是@Bean方法，如果是则转入特殊的处理流程。

Bean方法拦截的奥秘

在未被增强的普通Java类中，方法调用会直接执行方法体逻辑。但经过ConfigurationClassEnhancer增强后，@Bean方法的调用行为发生了本质变化：

首次调用：当某个@Bean方法第一次被调用（无论是外部直接获取还是被其他@Bean方法调用），拦截器会正常执行方法体逻辑，创建Bean实例并注册到容器中。
后续调用：相同方法再次被调用时，拦截器会从BeanFactory中直接返回已存在的Bean实例，而不会再次执行方法体。这正是实现单例模式的关键。

这种机制通过方法拦截器的resolveBeanReference()方法实现：

private Object resolveBeanReference(Method beanMethod, Object[] args) {
    // 获取BeanFactory
    ConfigurableListableBeanFactory beanFactory = getBeanFactory();
    // 通过Bean名称查找现有实例
    String beanName = BeanAnnotationHelper.determineBeanNameFor(beanMethod);
    return beanFactory.getBean(beanName);
}

增强类的字段注入

ConfigurationClassEnhancer还会为生成的子类添加一个特殊字段$$beanFactory，用于持有BeanFactory引用：

private static final String BEAN_FACTORY_FIELD = "$$beanFactory";

这个字段通过BeanFactoryAwareMethodInterceptor拦截器注入值，使得所有增强后的配置类实例都能访问到当前的BeanFactory。这种设计既保持了代码的简洁性，又实现了必要的功能耦合。

实际增强过程解析

具体增强过程发生在enhance()方法中：

首先检查目标类是否已经是增强类（实现了EnhancedConfiguration接口）
创建CGLIB的Enhancer实例，设置超类为原始配置类
配置回调过滤器和回调数组
使用SpringObjenesis创建代理实例，避免调用构造方法

public Class<?> enhance(Class<?> configClass, ClassLoader classLoader) {
    if (EnhancedConfiguration.class.isAssignableFrom(configClass)) {
        return configClass;  // 已经是增强类则直接返回
    }
    Class<?> enhancedClass = createClass(newEnhancer(configClass, classLoader));
    return enhancedClass;
}

性能优化细节

Spring在实现增强时考虑了多种优化措施：

缓存机制：相同的配置类只会被增强一次，后续直接使用缓存结果
延迟加载：Bean实例的实际创建延迟到第一次方法调用时
条件过滤：通过ConditionalCallbackFilter确保只有特定方法被拦截

与Lite模式的本质区别

对比Lite模式，Full模式的增强带来了显著的行为差异。在以下示例中：

@Configuration
public class AppConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB());  // 这里调用另一个@Bean方法
    }
    
    @Bean 
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

在Full模式下，serviceA()中对serviceB()的调用会被拦截，转而从容器获取ServiceB实例；而在Lite模式下，这将是普通的Java方法调用，每次都会创建新的ServiceB实例。这种差异正是ConfigurationClassEnhancer通过字节码增强实现的魔法效果。

源码解析：ConfigurationClassUtils

在Spring框架的配置类处理机制中，ConfigurationClassUtils扮演着至关重要的"侦察兵"角色。这个位于org.springframework.context.annotation包下的工具类，虽然不直接参与Bean的创建和增强，但却是决定配置类采用Full模式还是Lite模式的第一道关卡。

配置类识别的核心机制

ConfigurationClassUtils通过静态代码块初始化了一组关键标识：

private static final Set<String> candidateIndicators = new HashSet<>(8);
static {
    candidateIndicators.add(Component.class.getName());
    candidateIndicators.add(ComponentScan.class.getName());
    candidateIndicators.add(Import.class.getName());
    candidateIndicators.add(ImportResource.class.getName());
}

这些标识构成了Spring识别配置类的基础规则集。当处理一个候选类时，框架会通过checkConfigurationClassCandidate方法进行多维度检测：

注解扫描：检查类是否带有@Configuration、@Component等特定注解
代理模式验证：对@Configuration注解特别检查proxyBeanMethods属性
元数据标记：最终在BeanDefinition中设置CONFIGURATION_CLASS_ATTRIBUTE属性

模式判定的精确逻辑

ConfigurationClassUtils定义了两种核心模式标识常量：

public static final String CONFIGURATION_CLASS_FULL = "full";
public static final String CONFIGURATION_CLASS_LITE = "lite";

其判定逻辑呈现出清晰的层次结构：

Full模式触发条件：
- 类必须标注@Configuration注解
- proxyBeanMethods属性为true（默认值）或未显式设置为false
- 典型特征：允许跨@Bean方法调用时通过CGLIB代理确保单例
Lite模式判定场景：
- 标注@Component、@ComponentScan等注解的类
- @Configuration(proxyBeanMethods = false)的显式声明
- 包含@Bean方法的普通类
- 特征：@Bean方法如同普通工厂方法，每次调用都创建新实例

属性标记的底层实现

在BeanDefinition的处理过程中，ConfigurationClassUtils会通过以下关键操作完成标记：

public static void processConfigurationClass(
    ConfigurationClass configClass, Predicate<String> condition...
) {
    // 设置配置类属性
    beanDef.setAttribute(
        CONFIGURATION_CLASS_ATTRIBUTE,
        isFullConfigurationCandidate(metadata) ? CONFIGURATION_CLASS_FULL : CONFIGURATION_CLASS_LITE
    );
}

这个标记过程直接影响后续ConfigurationClassPostProcessor的处理策略。通过分析Spring 5.3.x的源码可以发现，在ConfigurationClassParser的doProcessConfigurationClass方法中，会严格根据这个属性值决定是否需要进行CGLIB增强。

典型场景的差异表现

考虑以下两种配置类声明方式：

// Full模式示例
@Configuration
public class FullConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB()); // 通过代理确保单例
    }
    
    @Bean 
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

// Lite模式示例
@Component
public class LiteConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(serviceB()); // 每次调用创建新实例
    }
    
    @Bean
    public ServiceB serviceB() {
        return new ServiceB();
    }
}

ConfigurationClassUtils的识别结果直接决定了这两种配置类的运行时行为差异。在Full模式下，serviceA()调用serviceB()会通过代理机制确保获取容器管理的单例；而Lite模式下则是直接的Java方法调用，每次都会创建新的ServiceB实例。

元数据处理的高级特性

除了基本的模式识别，ConfigurationClassUtils还负责处理一些衍生功能：

排序标记：通过ORDER_ATTRIBUTE为配置类定义处理顺序
嵌套配置识别：处理@Configuration类中的内部类配置
条件过滤：与@Conditional注解配合进行条件化配置

在Spring Boot 2.7+版本中，这些功能被进一步优化，特别是在处理自动配置类的排序和过滤时，ConfigurationClassUtils与AutoConfigurationImportSelector形成了紧密的协作机制。

通过深度分析ConfigurationClassUtils的实现细节，我们可以清晰看到Spring如何在底层建立配置类的处理管道。这种设计既保证了框架的灵活性（通过Lite模式支持轻量级配置），又通过Full模式提供了完备的容器管理能力。这种双模式机制正是Spring"约定优于配置"理念的典型体现，开发者可以根据具体场景选择最适合的配置方式。

面试题解析：@Bean方法间的调用

在Spring面试中，@Bean方法间的调用行为是高频考点，也是考察候选人对Spring容器机制理解深度的绝佳切入点。让我们通过一个典型场景切入：当在@Configuration类中，一个@Bean方法内部调用另一个@Bean方法时，究竟会发生什么？这个看似简单的问题背后，隐藏着Spring容器对Bean生命周期的精妙控制。

现象观察：两种截然不同的行为

考虑以下两种配置类写法：

// 写法A：标准@Configuration类
@Configuration
public class FullConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(dependencyB());
    }
    
    @Bean 
    public DependencyB dependencyB() {
        return new DependencyB();
    }
}

// 写法B：使用@Component替代@Configuration
@Component
public class LiteConfig {
    @Bean
    public ServiceA serviceA() {
        return new ServiceA(dependencyB());
    }
    
    @Bean
    public DependencyB dependencyB() {
        return new DependencyB();
    }
}

在写法A中，当调用serviceA()方法时，通过dependencyB()获取的会是容器中唯一的单例对象；而在写法B中，每次调用dependencyB()都会创建新的实例。这种差异正是Full模式与Lite模式的核心区别体现。

机制解析：CGLIB代理的魔法

Full模式下，Spring通过ConfigurationClassEnhancer对@Configuration类进行CGLIB增强，生成子类代理。当调用被@Bean注解的方法时，代理逻辑会先检查容器中是否已存在该Bean：

若存在则直接返回容器中的实例
若不存在才执行原始方法创建新实例
将新创建的实例立即注册到容器

这个过程通过拦截器实现，核心逻辑在ConfigurationClassEnhancer.BeanMethodInterceptor中：

// 简化后的拦截逻辑
public Object intercept(Object enhancedConfigInstance, Method beanMethod, 
    Object[] args, MethodProxy methodProxy) throws Throwable {
    
    BeanFactory beanFactory = getBeanFactory(enhancedConfigInstance);
    String beanName = BeanFactoryUtils.qualifiedBeanNameOf(beanMethod);
    
    if (beanFactory.containsBean(beanName)) {
        return beanFactory.getBean(beanName);
    }
    
    return methodProxy.invokeSuper(enhancedConfigInstance, args);
}

而Lite模式下（如使用@Component或@Configuration(proxyBeanMethods=false)），配置类不会被增强，方法调用就是普通的Java方法调用，无法实现上述拦截逻辑。

源码追踪：模式识别的关键

ConfigurationClassUtils.checkConfigurationClassCandidate()方法负责判断类的模式：

// 关键判断逻辑
if (config != null && !Boolean.FALSE.equals(config.get("proxyBeanMethods"))) {
    beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_FULL);
} else if (config != null || isConfigurationCandidate(metadata)) {
    beanDef.setAttribute(CONFIGURATION_CLASS_ATTRIBUTE, CONFIGURATION_CLASS_LITE);
}

这个判断决定了后续ConfigurationClassPostProcessor处理配置类时是否启用增强逻辑。

面试深度扩展问题

为什么Spring默认采用Full模式？ 为了保证配置类中@Bean方法间的调用都能获取到容器管理的单例，避免意外创建多个实例，这是Spring认为更安全的行为模式。

什么情况下应该使用Lite模式？ 当配置类中没有@Bean方法间的调用，或者明确希望每次调用都创建新实例时。Lite模式避免了CGLIB代理的开销，启动速度更快。

如何显式指定模式？ 通过@Configuration的proxyBeanMethods属性：

@Configuration(proxyBeanMethods = false) // 显式指定Lite模式
public class MyConfig {...}

方法调用的循环依赖问题 在Full模式下，Spring能处理配置类中@Bean方法的循环调用（通过提前暴露代理对象），而Lite模式会导致栈溢出。

实际应用中的陷阱

一个常见错误是在Lite模式的配置类中无意识地调用@Bean方法：

@Component
public class ProblemConfig {
    @Bean
    public A a() { return new A(b()); } // 每次都会new B()
    
    @Bean 
    public B b() { return new B(); }
}

这种情况下，每次获取A实例时都会创建新的B实例，可能完全违背开发者的预期。正确的做法应该是通过参数注入：

@Component
public class CorrectConfig {
    @Bean
    public A a(B b) { return new A(b); } // 注入容器中的B
    
    @Bean 
    public B b() { return new B(); }
}

理解这个机制对排查诡异的Bean实例化问题至关重要，也是区分Spring初级和高级开发者的重要标志之一。

结语：选择适合的模式

在Spring框架的实际开发中，Full模式和Lite模式的选择需要根据具体场景权衡利弊。通过前文的源码分析我们已经了解到，ConfigurationClassPostProcessor通过ConfigurationClassUtils.checkConfigurationClassCandidate方法识别配置类类型，而ConfigurationClassEnhancer则专门负责对Full模式配置类进行CGLIB增强。

Full模式的核心优势体现在其严格的单例保证机制上。当配置类被CGLIB增强后，所有@Bean方法间的调用都会经过代理拦截，确保始终返回容器中的单例对象。这在需要严格依赖管理的复杂场景中尤为重要，比如：

数据库连接池等需要全局唯一实例的基础设施组件
存在交叉依赖的Bean初始化场景
需要方法拦截等AOP增强的配置类

但Full模式的代价也不容忽视。根据Spring官方文档显示，CGLIB增强会导致：

应用启动时间增加约15-20%（基于2024年Spring Boot 3.2基准测试）
元数据内存占用提升30%左右
某些IDE调试时可能遇到代理类识别问题

Lite模式的轻量级特性使其在以下场景更具优势：

性能敏感型应用：如需要快速启动的Serverless函数
简单配置场景：当@Bean方法间没有调用关系时
单元测试环境：避免代理带来的测试复杂度
已有外部单例管理机制的情况

值得注意的是，Spring Boot 3.x系列对Lite模式进行了多项优化：

改进了@Bean方法循环引用的检测机制
增强了配置类加载的并行处理能力
提供了更清晰的模式冲突警告日志

在实际项目决策时，建议采用以下实践方案：

默认选择Full模式：特别是在团队协作或复杂项目中，其严格的单例保证能避免许多隐蔽问题
显式声明模式：即使使用Lite模式，也建议通过@Configuration(proxyBeanMethods=false)明确标识
分层配置策略：核心基础设施使用Full模式，边缘服务采用Lite模式
性能监控：在Spring Actuator中关注"beans"端点的初始化时间指标

对于微服务架构，2025年的最新实践表明：

网关层配置推荐Full模式确保路由单例
业务服务内部模块可使用Lite模式提升启动速度
混合部署时要注意ContextRefreshedEvent的触发时序差异

在持续交付流水线中，可以通过Spring Boot的SpringApplication.setLazyInitialization方法动态调整初始化策略，实现测试环境快速验证与生产环境稳定运行的平衡。

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2025-08-27，如有侵权请联系 cloudcommunity@tencent.com 删除

spring

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！