Spring Bean 作用域、生命周期与自动装配深度解析

这里有个坑需要注意：直接通过 context.getBean() 获取会触发新实例创建（针对非单例）。但当你使用 @Autowired 或 @Resource 注入原型（Prototype）作用域的 Bean 时，注入操作仅在容器初始化阶段执行一次，后续访问的都是最初注入的实例。

对于 Request 作用域，Spring 注入了一个代理对象。这个代理在启动时就被注入到单例 Bean 中，但真实实例的创建被延迟到了 HTTP 请求发生时。代理内部持有当前请求上下文，调用方法时会查找或创建新的实例，确保每个请求线程都能获得独立副本。

• Singleton(单例)：默认作用域，整个容器中仅存在一个实例。
• Prototype(原型)：每次请求 Bean 时都会创建新实例。
• Request(请求)：每个 HTTP 请求创建一个新实例。
• Session(会话)：每个用户会话创建一个实例。
• Application(应用)：整个 Web 应用共享一个实例。

Bean 的生命周期

Bean 的生命周期涵盖了从创建到销毁的全过程，主要分为五个阶段：

1. 实例化：容器通过反射调用构造器创建对象。
2. 属性赋值：依赖注入（如 @Autowired）在此阶段完成。
3. 初始化：
   • 通知方法调用：实现 BeanNameAware 等接口注入框架信息。
   • 前置处理：BeanPostProcessor.postProcessBeforeInitialization，做参数校验或资源加载。
   • 初始化回调：实现 InitializingBean 的 afterPropertiesSet 或自定义 init-method。
   • 后置处理：BeanPostProcessor.postProcessAfterInitialization，常用于 AOP 代理生成。
4. 使用 Bean：进入就绪状态，可被调用。
5. 销毁 Bean：容器关闭时触发 @PreDestroy 等方法。

示例

/**
 * 实体类
 */
public class Cat {}

/**
 * 配置类
 */
@Configuration
public class CatConfig {
    @Bean
    public Cat cat() {
        return new Cat();
    }
}

/**
 * 实现类
 */
@Component
@Slf4j
public class BeanLifeComponent implements BeanNameAware, BeanPostProcessor, InitializingBean {
    private Cat cat;

    // 1. 实例化
    public BeanLifeComponent() {
        log.info("1.实例化：执行构造方法");
    }

    // 2. 属性赋值
    @Autowired
    public void setCat(Cat cat) {
        log.info("2.属性赋值：执行 setter 方法");
        this.cat = cat;
    }

    // 3.1 通知方法调用
    @Override
    public void setBeanName(String name) {
        log.info("3.1 通知方法调用，bean name is {}", name);
    }

    // 3.2 前置处理
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        log.info("3.3 前置处理，bean:{},beanName:{}", bean, beanName);
        return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
    }

    // 3.3 初始化回调
    @Override
    public void afterPropertiesSet() {
        log.info("3.2 初始化回调");
    }

    // 3.4 后置处理
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        log.info("3.4 后置处理，bean:{},beanName:{}", bean, beanName);
        return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
    }

    // 4. 使用 Bean
    public void use() {
        log.info("4.使用 Bean");
    }

    // 5. 销毁 Bean
    @PreDestroy
    public void preDestroy() {
        log.info("5.销毁 Bean");
    }
}

/**
 * 测试类
 */
@SpringBootTest
class SpringPrincipleApplicationTests {
    private final ApplicationContext context;

    @Autowired
    public SpringPrincipleApplicationTests(ApplicationContext context) {
        this.context = context;
    }

    @Test
    public void test() {
        BeanLifeComponent beanLifeComponent = context.getBean(BeanLifeComponent.class);
        beanLifeComponent.use();
    }
}

运行日志可能会让你困惑：为什么显示的是 invokeInitMethods 在前，而源码逻辑似乎是先处理？

关键在于：BeanPostProcessor 本身也是 Bean。当 Spring 初始化一个实现了 BeanPostProcessor 的类（如上面的 BeanLifeComponent）时，这个过程是递归的。

1. 创建普通 Bean 时，按顺序执行：Before → Init → After。
2. 创建 BeanPostProcessor Bean 时，Spring 需要先让它自己完成初始化（包括调用 invokeInitMethods），才能将其加入列表供其他 Bean 使用。
3. 但对于这个 Processor 自身而言，它的 postProcessBeforeInitialization 和 postProcessAfterInitialization 方法不会在它自己的创建过程中被调用！

所以日志显示的其实是该 BeanPostProcessor 自身的初始化过程：先执行了它自己的 afterPropertiesSet（初始化回调），然后才轮到它去处理其他 Bean 的前置/后置逻辑。这解释了看似矛盾的执行顺序。

SpringBoot 自动装配

自动装配的核心是'约定大于配置'。Spring Boot 启动时会自动扫描依赖包中的配置类和 Bean，无需手动注册。

加载原理

引入第三方依赖后，Spring Boot 能识别并加载其中的配置。如果组件不在默认扫描路径下，就需要手动干预。

1. @ComponentScan

告诉容器去哪里扫描标记了 @Component 等注解的类。

@SpringBootApplication
@ComponentScan("com.example.springprincicle.component")
public class SpringPrincipleApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringPrincipleApplication.class, args);
    }
}

2. @Import

用于显式导入配置类或组件。

@SpringBootApplication
@Import(TestConfig.class)
public class SpringPrincipleApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringPrincipleApplication.class, args);
    }
}

或者通过 ImportSelector 接口动态选择：

public class MyImportSelector implements ImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata importingClassMetadata) {
        return new String[]{"com.example.springprincicle.component.TestConfig"};
    }
}

为了封装复杂度，通常由依赖方提供一个自定义注解，内部封装 @Import。

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
@Import(MyImportSelector.class)
@interface EnableTestConfig {}

@SpringBootApplication
@EnableTestConfig
public class SpringPrincipleApplication {
    public static void main(String[] args) {
        SpringApplication.run(SpringPrincipleApplication.class, args);
    }
}

@SpringBootApplication 源码解析

这是一个组合注解，包含三个核心部分：

1. @ComponentScan：默认扫描启动类所在包及其子包。
2. @SpringBootConfiguration：标记为配置类，提供索引支持加速启动。
3. @EnableAutoConfiguration：这是自动装配的入口。

@EnableAutoConfiguration 背后是 AutoConfigurationImportSelector 类，它实现了 DeferredImportSelector 接口，负责动态加载自动配置类。

在 getCandidateConfigurations 方法中，Spring Boot 会扫描类路径下的 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件（Spring Boot 3.x 新机制），读取所有自动配置类名。旧版本则依赖 META-INF/spring.factories。

这种设计保证了向后兼容性，同时让第三方库只需将配置类定义在指定文件中，即可在启动时被自动发现并加载到 IoC 容器。

完整源码已开源，方便对照阅读。