Spring注解驱动开发深度解析：从原理到实战，彻底掌握IoC、AOP与条件装配-三亩地-编程学习日记

1. 项目概述与初衷

如果你是一名Java开发者，尤其是经历过从Spring 2.x的XML配置时代一路走来的老手，看到“注解驱动开发”这几个字，内心大概会涌起一股复杂的情绪。那是一个在applicationContext.xml里写满<bean>和<property>标签的年代，配置文件动辄上千行，查找一个依赖关系如同大海捞针。后来，Spring引入了注解，从@Autowired、@Service的星星之火，到如今Spring Boot约定大于配置的燎原之势，注解彻底改变了我们编写和配置Spring应用的方式。它让代码更简洁，意图更清晰，但同时也带来了新的挑战：注解背后的原理是什么？@Configuration和@ComponentScan是如何协作的？条件装配@Conditional的魔法是怎么实现的？为什么我的@Transactional有时会失效？

市面上很多教程，要么停留在“如何使用”的层面，像一本命令手册；要么直接深入源码，让人望而生畏。我总觉得缺少一个桥梁，一个能系统性地、由浅入深地，把注解驱动开发的“为什么”和“怎么做”讲透的系列。这就是我花费三个月时间，打磨这个系列教程的初衷。这不是一个简单的API罗列，而是一次对Spring IoC容器、AOP、事务管理、后置处理器等核心机制，在注解驱动语境下的深度解构。目标很明确：让你不仅会用注解，更能懂注解，甚至能基于其扩展原理，解决实际开发中的复杂问题。无论你是想面试突围，还是想彻底玩转Spring，这个系列都将为你提供一个全新的、震撼的视角。

2. 教程核心设计思路与架构拆解

2.1 为什么是“注解驱动”深度，而非“Spring Boot”快速入门？

很多学习者一上来就直奔Spring Boot，这当然没错，它能极快地搭建项目。但问题也随之而来：当出现自动配置不生效、自定义Starter有冲突、事务传播行为异常时，往往会陷入茫然。因为Spring Boot的魔法，其根基正是Spring Framework的注解驱动模型。@SpringBootApplication注解本身就是一个复合注解，它整合了@Configuration、@ComponentScan和@EnableAutoConfiguration。如果你不理解@Configuration类是如何被ConfigurationClassPostProcessor这个后置处理器解析并注册Bean定义的，你就很难理解为什么你的自定义配置类有时不生效。

因此，本系列采取“自底向上”的拆解策略。我们先抛开Spring Boot的“自动驾驶”模式，回到最“手动”的AnnotationConfigApplicationContext，从最纯净的注解配置上下文开始。这样做的目的是剥离框架的便利性外衣，直击核心引擎。我们会详细追踪一个标注了@Configuration的Java类，从被上下文加载，到被后置处理器解析，最终变成容器内一个个Bean定义的完整过程。这个过程理解了，Spring Boot的自动配置无非是在这个核心流程上，增加了按条件（@Conditional）批量注册@Configuration类的机制而已。这种深度，能让你在遇到问题时，拥有从根本机制上进行推理和排查的能力，而不是盲目地搜索和试错。

2.2 内容编排的三层递进结构

为了确保学习的系统性和深度，整个教程被设计为三个大的层次，环环相扣。

第一层：基石篇——注解与容器启动流程。这一部分是整个大厦的地基。我们会从AnnotationConfigApplicationContext的refresh()方法开始，深入探讨BeanFactoryPostProcessor和BeanPostProcessor这两个扩展点的核心地位。重点剖析ConfigurationClassPostProcessor，它是注解驱动的“翻译官”，负责扫描@ComponentScan指定的路径，解析@Configuration类中的@Bean方法、@Import注解等。我们会用大量的流程图和调试截图，展示一个@Component注解的类，是如何一步步被扫描、解析，最终成为一个BeanDefinition的。同时，会彻底讲清楚@Scope、@Lazy、@DependsOn等基础注解在Bean定义阶段的影响。

第二层：核心篇——依赖注入、AOP与事务的注解化实现。当地基稳固后，我们开始建造主体结构。这一部分聚焦于Spring最核心的三大功能：IoC、AOP、事务，并看它们是如何通过注解优雅实现的。

依赖注入：超越@Autowired和@Resource用法的简单对比，深入AutowiredAnnotationBeanPostProcessor的工作机制。解释为什么构造器注入被推荐，@Autowired(required=false)在什么场景下有用，以及如何利用@Qualifier或自定义注解解决同一类型多个Bean的注入歧义问题。
AOP：详细解读@Aspect、@Before、@After、@Around等注解。关键不在于如何使用，而在于Spring是如何在运行时，为被@Transactional或自定义@Aspect标注的Bean创建代理对象的。我们会分析JDK动态代理和CGLIB代理的选择策略，以及@EnableAspectJAutoProxy中proxyTargetClass参数的真实含义和影响。
事务管理：这是AOP的经典应用案例。我们会深入@EnableTransactionManagement注解，追踪TransactionInterceptor这个AOP通知是如何被织入的。详细讲解@Transactional的propagation（传播行为）、isolation（隔离级别）、rollbackFor等属性的工作原理，并结合数据库连接和线程绑定的概念，解释为什么在同一个类中自调用事务方法会失效这个经典问题。

第三层：高级篇：条件装配、生命周期与扩展定制。这是让你从“使用者”变为“驾驭者”的关键。我们将探索Spring强大的可扩展性。

条件装配：深入分析@Conditional注解和Condition接口，这是Spring Boot自动配置的基石。我们会手写几个自定义条件注解，例如根据系统属性、Bean是否存在或特定类是否存在来决定是否注册某个配置类，让你彻底理解spring-boot-autoconfigure模块的工作原理。
Bean生命周期：结合注解，详细拆解Bean从实例化、属性填充、初始化到销毁的完整过程。重点讲解@PostConstruct、@PreDestroy以及InitializingBean、DisposableBean接口的执行顺序。并通过BeanPostProcessor接口，演示如何在实际初始化前后对Bean进行定制化处理（例如，对所有Bean进行字段加密解密）。
定制化扩展：学习如何编写自己的@EnableXXX注解。通过模仿@EnableCaching或@EnableAsync，我们来实现一个简单的@EnableHelloWorld注解，它通过@Import导入一个配置类，自动向容器注册一个特定的Bean。这个过程会让你对Spring的“模块化”设计有更深的理解。

3. 核心模块深度解析与实战要点

3.1 注解配置的基石：@Configuration 与 @Bean 的隐秘角落

@Configuration标注的类，通常被称为“配置类”。但它的本质是一个被CGLIB增强（proxyBeanMethods = true时）的Full配置类，以确保其中@Bean方法相互调用时，总是返回容器中的单例，而不是每次调用都创建一个新的实例。这是很多人在初学时容易混淆的点。

实战要点与避坑指南：

proxyBeanMethods的抉择：在Spring Boot 2.2之后，@Configuration(proxyBeanMethods = false)成为一个常见选项。设为false时，配置类不会被代理，@Bean方法之间的直接调用就是普通的Java方法调用，会执行方法体并返回新对象。这能略微提升启动速度，适用于Bean之间无依赖、或你明确知道调用方式的情况。但在大多数需要保证单例的复杂场景下，保持默认的true更安全。
```
@Configuration(proxyBeanMethods = false) // 轻量级模式，适用于无内部Bean依赖的配置 public class MyConfig { @Bean public A a() { return new A(b()); // 注意！这里每次调用a()，都会执行b()方法，产生新的B实例！ } @Bean public B b() { return new B(); } }
```

@Bean方法的参数注入：@Bean方法可以接收参数，Spring会自动从容器中寻找匹配的Bean进行注入。这是实现条件化Bean装配的巧妙方式。

@Bean public DataSource dataSource(Environment env) { // 自动注入Environment对象 HikariConfig config = new HikariConfig(); config.setJdbcUrl(env.getProperty("spring.datasource.url")); // ... 其他配置 return new HikariDataSource(config); }

Bean命名与别名：默认情况下，@Bean注解的方法名就是Bean的名称。你可以通过@Bean(“myBeanName”)显式指定。一个Bean可以有多个名称（别名），这在其内部实现BeanDefinition时有所体现。

3.2 组件扫描：@ComponentScan 的过滤器艺术

@ComponentScan不仅仅是指定一个basePackages。它的核心能力在于其包含和排除过滤器。

深度解析：@ComponentScan内部会使用ClassPathBeanDefinitionScanner进行扫描。你可以通过includeFilters和excludeFilters属性进行精细控制。过滤器类型（FilterType）有：

ANNOTATION：基于注解（默认）。
ASSIGNABLE_TYPE：基于指定类或接口。
ASPECTJ：使用AspectJ表达式。
REGEX：使用正则表达式。
CUSTOM：自定义TypeFilter实现。

实战案例：排除特定注解的类假设我们有一个自定义注解@InternalApi，用于标记内部实现类，不希望它们被扫描进主应用上下文。

@Configuration @ComponentScan(basePackages = "com.example", excludeFilters = @ComponentScan.Filter( type = FilterType.ANNOTATION, classes = InternalApi.class )) public class AppConfig { }

更强大的自定义过滤器：你可以实现TypeFilter接口，根据类名、资源路径等任意条件决定是否包含。

public class MyCustomFilter implements TypeFilter { @Override public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException { // 读取类的元数据 ClassMetadata classMetadata = metadataReader.getClassMetadata(); // 例如，只包含类名以“ServiceImpl”结尾的类 return classMetadata.getClassName().endsWith("ServiceImpl"); } } // 在@ComponentScan中使用 excludeFilters = @ComponentScan.Filter(type = FilterType.CUSTOM, classes = MyCustomFilter.class)

3.3 条件化装配：@Conditional 与 Spring Boot 自动配置的奥秘

@Conditional是Spring 4.0引入的革命性注解，它使得Bean的注册行为可以根据特定条件动态决定。Spring Boot的@EnableAutoConfiguration和大量的@Configuration类都重度依赖它。

原理解析：@Conditional注解接收一个或多个实现了Condition接口的类。Condition接口只有一个matches方法，返回boolean。在容器处理配置类或@Bean方法时，会调用相应Condition的matches方法，只有返回true，对应的Bean定义才会被注册。

手写一个条件注解：假设我们有一个功能模块，只在生产环境（prod）才需要启用。

定义条件类：

public class OnProductionEnvironmentCondition implements Condition { @Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { Environment env = context.getEnvironment(); // 判断激活的配置文件是否包含`prod` return Arrays.asList(env.getActiveProfiles()).contains("prod"); } }

使用条件注解：

@Configuration public class ProductionOnlyConfig { @Bean @Conditional(OnProductionEnvironmentCondition.class) // 仅在生产环境创建 public MonitoringService monitoringService() { return new MonitoringService(); } }

Spring Boot的条件注解：Spring Boot提供了大量开箱即用的条件注解，它们都是@Conditional的派生注解，更语义化：

@ConditionalOnClass：类路径下存在指定类时生效。
@ConditionalOnMissingBean：容器中不存在指定Bean时生效（这是实现“默认配置可覆盖”的关键）。
@ConditionalOnProperty：配置文件中存在指定属性且匹配值时生效。
@ConditionalOnWebApplication：是Web应用时生效。理解这些注解，是阅读spring-boot-autoconfigure源码和自定义Starter的必备技能。

4. 依赖注入与AOP的注解化实现内幕

4.1 @Autowired 的注入原理与各种变体场景

@Autowired默认按类型（byType）注入。当存在多个同类型Bean时，会再按名称（byName）匹配。如果还无法确定，则抛出NoUniqueBeanDefinitionException。

注入点详解：

构造器注入（推荐）：从Spring 4.3开始，如果类只有一个构造器，@Autowired可以省略。这是注入不可变依赖和保证依赖完整性的最佳方式。

@Service public class UserService { private final UserRepository repository; // @Autowired 可省略 public UserService(UserRepository repository) { this.repository = repository; } }

Setter/字段注入：较为灵活，但可能导致对象处于部分依赖状态。字段注入虽然简洁，但不利于测试（必须通过反射）和不变性保证。
方法注入：任何标注了@Autowired的方法，Spring会在Bean创建后，属性填充阶段调用它，并自动注入参数。

处理多个候选Bean：

@Qualifier：指定Bean的名称。可以与@Bean注解或组件扫描生成的Bean名称配合使用。

@Component @Qualifier("main") public class MainDataSource implements DataSource { ... } @Autowired @Qualifier("main") private DataSource dataSource;

@Primary：设置首选Bean。当有多个同类型Bean且未指定@Qualifier时，会注入标记了@Primary的那个。

自定义限定符注解：创建自定义注解，元标注@Qualifier，使代码更语义化。

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) @Retention(RetentionPolicy.RUNTIME) @Qualifier public @interface MainDatabase { } @Component @MainDatabase public class MainDataSource implements DataSource { ... }

4.2 AOP注解驱动：从 @Aspect 到代理对象的诞生

使用@EnableAspectJAutoProxy开启AspectJ风格的AOP支持后，Spring会注册一个关键的BeanPostProcessor——AnnotationAwareAspectJAutoProxyCreator。

核心流程：

发现切面：在Bean创建后初始化前，AnnotationAwareAspectJAutoProxyCreator会扫描容器中所有Bean，找到被@Aspect注解的类。
构建通知链：解析@Aspect类中的@Before、@After、@Around等注解方法，根据其切点表达式（@Pointcut）构建一个个Advice（通知）。
创建代理：对于其他普通的Bean，在初始化完成后，BeanPostProcessor会检查该Bean是否匹配任何切点表达式。如果匹配，则不会返回原始Bean，而是创建一个代理对象（JDK动态代理或CGLIB代理）来包装它。
方法调用拦截：当通过代理对象调用方法时，代理会根据方法匹配的切点，按顺序执行相应的通知链（前置通知、环绕通知、后置通知等）。

关键选择：JDK代理 vs CGLIB代理

JDK动态代理：基于接口。要求目标类至少实现一个接口。代理对象是接口类型。
CGLIB代理：基于继承。通过生成目标类的子类来创建代理。可以代理没有接口的类。
控制参数：@EnableAspectJAutoProxy(proxyTargetClass = true)会强制使用CGLIB代理。默认为false，即优先使用JDK代理，不行再回退到CGLIB。在Spring Boot 2.x之后，默认行为已改为优先使用CGLIB（proxyTargetClass默认为true），以支持更多场景。

一个常见的坑：自调用失效由于AOP代理是基于“外部调用”的，在同一个类中，一个方法A直接调用另一个被@Transactional或自定义切面增强的方法B，这次调用是不会经过代理对象的，因此切面逻辑不会生效。解决方法是注入自身的代理（通过AopContext.currentProxy()或更优雅地，通过注入ApplicationContext获取自身Bean）或重构代码将方法B放到另一个Bean中。

4.3 @Transactional 事务注解的传播行为与失效场景全解

@Transactional是Spring声明式事务管理的核心，其本质是一个使用了AOP的环绕通知（TransactionInterceptor）。

传播行为（Propagation）详解：这是事务注解中最复杂也最重要的概念，定义了被注解方法如何参与或创建事务。

REQUIRED（默认）：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。这是最常用的设置。
REQUIRES_NEW：无论当前是否存在事务，都创建一个新的事务。新事务与旧事务独立，新事务提交或回滚不影响旧事务。适用于需要独立记录的日志操作等。
NESTED：如果当前存在事务，则在嵌套事务内执行。嵌套事务是外部事务的子事务，有自己的保存点。子事务回滚不影响外部事务，但外部事务回滚会导致子事务也回滚。注意：需要数据库支持保存点（如MySQL的InnoDB）。
SUPPORTS：如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务方式执行。
NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，则将其挂起。
NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
MANDATORY：必须在事务中运行，如果当前没有事务，则抛出异常。

经典失效场景与排查：

自调用失效：同上述AOP自调用问题。方法A调用同类中的方法B，即使B有@Transactional，事务也不会生效。
异常类型未被捕获：默认只对运行时异常（RuntimeException）和错误（Error）进行回滚。受检异常（Exception）不会触发回滚。需要通过@Transactional(rollbackFor = Exception.class)来指定。
方法修饰符为非public：Spring AOP（默认使用JDK动态代理或CGLIB）对于非public方法，代理可能无法正常工作，导致事务注解失效。应始终将事务方法声明为public。
数据库引擎不支持事务：例如MySQL的MyISAM引擎不支持事务，即使注解配置正确也无济于事。需使用InnoDB引擎。
在同一个类中，一个未加注解的方法调用另一个@Transactional方法：这本质也是自调用问题。

try-catch吞掉异常：如果在方法内用try-catch捕获了异常，但没有重新抛出，事务拦截器就感知不到异常，自然不会回滚。

@Transactional public void updateUser() { try { userRepository.update(...); // 发生异常... } catch (Exception e) { // 仅仅打印日志，没有抛出！ log.error("error", e); // 事务不会回滚！ } }

5. 高级特性：生命周期管理与定制化扩展实战

5.1 完整的Bean生命周期与注解干预点

理解Bean的生命周期，是进行高级定制和问题排查的基础。结合注解，我们可以清晰地看到干预点。

生命周期阶段与对应注解/接口：

实例化（Instantiation）：调用构造器创建Bean实例。
属性赋值（Population）：为Bean的属性注入值（通过@Autowired、@Value等）。
BeanPostProcessor前置处理：BeanPostProcessor.postProcessBeforeInitialization方法被调用。这是一个通用扩展点。
初始化（Initialization）：
- 执行@PostConstruct注解的方法。
- 执行InitializingBean.afterPropertiesSet()方法（如果实现了该接口）。
- 执行自定义的init-method（通过@Bean(initMethod = “…”）指定）。
BeanPostProcessor后置处理：BeanPostProcessor.postProcessAfterInitialization方法被调用。AOP代理就是在此阶段创建的！
Bean就绪：此时Bean已完全初始化，可供使用。
销毁（Destruction）：容器关闭时。
- 执行@PreDestroy注解的方法。
- 执行DisposableBean.destroy()方法（如果实现了该接口）。
- 执行自定义的destroy-method（通过@Bean(destroyMethod = “…”）指定）。

执行顺序示例：对于一个同时使用了@PostConstruct、实现了InitializingBean并指定了init-method的Bean，其初始化方法的执行顺序是固定的：@PostConstruct→afterPropertiesSet()→init-method。这有助于我们在不同阶段执行特定逻辑。

5.2 实现一个自定义的 @EnableHelloWorld 模块

让我们通过一个完整的实战，将前面所学的@Configuration、@Bean、@Conditional、@Import等知识串联起来，实现一个简单的@EnableHelloWorld注解，它能够自动向容器注册一个HelloWorldServiceBean。

第一步：定义核心功能组件

// 这是一个简单的服务类，我们将通过自动配置来注册它 public class HelloWorldService { public String sayHello() { return "Hello, World from Auto Configuration!"; } }

第二步：创建自动配置类

@Configuration // 声明这是一个配置类 @ConditionalOnMissingBean(HelloWorldService.class) // 条件：当容器中不存在HelloWorldService类型的Bean时才生效 public class HelloWorldAutoConfiguration { @Bean // 向容器注册一个HelloWorldService的Bean public HelloWorldService helloWorldService() { return new HelloWorldService(); } }

第三步：创建选择器（Selector）这是@EnableXXX模式的核心。我们创建一个ImportSelector的实现，它负责决定导入哪些配置类。

public class HelloWorldImportSelector implements ImportSelector { @Override public String[] selectImports(AnnotationMetadata importingClassMetadata) { // 返回需要导入的配置类的全限定名 return new String[] {HelloWorldAutoConfiguration.class.getName()}; } }

第四步：创建最终的 @EnableHelloWorld 注解

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Import(HelloWorldImportSelector.class) // 关键：通过@Import导入我们的选择器 public @interface EnableHelloWorld { // 可以定义一些属性，用于控制行为 String prefix() default "hello"; }

第五步：使用在主应用类或任意@Configuration类上添加@EnableHelloWorld注解。

@SpringBootApplication @EnableHelloWorld // 只需添加此注解 public class Application { public static void main(String[] args) { ConfigurableApplicationContext context = SpringApplication.run(Application.class, args); // 从容器中获取自动注册的Bean HelloWorldService service = context.getBean(HelloWorldService.class); System.out.println(service.sayHello()); // 输出: Hello, World from Auto Configuration! } }

通过这个简单的例子，你就能透彻理解Spring Boot中那些@EnableCaching、@EnableAsync等注解的工作原理了。它们都是基于@Import和ImportSelector（或ImportBeanDefinitionRegistrar）这套强大的扩展机制。

6. 综合实战：构建一个基于注解的简易监控模块

为了将所学融会贯通，我们设计一个实战项目：一个基于注解的轻量级方法执行监控模块。它能统计被注解方法的调用次数和平均耗时。

6.1 定义监控注解

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface Monitor { String value() default ""; // 可指定监控名称 }

6.2 实现监控切面

@Aspect @Component public class MonitorAspect { // 使用ConcurrentHashMap存储监控数据，key为方法签名 private final Map<String, MonitorData> monitorDataMap = new ConcurrentHashMap<>(); // 定义切点：所有被@Monitor注解的方法 @Pointcut("@annotation(com.example.demo.annotation.Monitor)") public void monitorPointcut() {} // 环绕通知，进行耗时统计 @Around("monitorPointcut()") public Object around(ProceedingJoinPoint joinPoint) throws Throwable { String methodSignature = joinPoint.getSignature().toLongString(); long startTime = System.currentTimeMillis(); Object result; try { result = joinPoint.proceed(); // 执行目标方法 } finally { long costTime = System.currentTimeMillis() - startTime; // 原子性地更新监控数据 monitorDataMap.compute(methodSignature, (key, oldData) -> { if (oldData == null) { return new MonitorData(1, costTime); } else { oldData.incrementCount(); oldData.addTotalTime(costTime); return oldData; } }); } return result; } // 提供一个接口供外部获取监控数据 public Map<String, MonitorData> getMonitorData() { return new HashMap<>(monitorDataMap); } // 监控数据内部类 public static class MonitorData { private int count; private long totalTime; // 构造器、getter、increment方法省略... public double getAverageTime() { return count == 0 ? 0 : (double) totalTime / count; } } }

6.3 创建自动配置与暴露端点

我们希望这个监控模块可以像Spring Boot Actuator一样，通过一个HTTP端点来查看数据。

创建配置类，注册切面和控制器

@Configuration @ConditionalOnWebApplication // 仅在Web应用中生效 @EnableAspectJAutoProxy // 确保AOP生效 public class MonitorAutoConfiguration { @Bean @ConditionalOnMissingBean public MonitorAspect monitorAspect() { return new MonitorAspect(); } @RestController @RequestMapping("/monitor") static class MonitorEndpoint { @Autowired private MonitorAspect monitorAspect; @GetMapping("/stats") public Map<String, MonitorData> getStats() { return monitorAspect.getMonitorData(); } } }

在resources/META-INF/spring.factories中注册自动配置（Spring Boot 2.7之前）或创建org.springframework.boot.autoconfigure.AutoConfiguration.imports文件（Spring Boot 2.7+）。
- Spring Boot 2.7+ (src/main/resources/META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports)：
```
com.example.demo.config.MonitorAutoConfiguration
```
使用：在其他业务方法上添加@Monitor注解，启动应用后，访问/monitor/stats即可看到监控数据。

这个实战项目综合运用了自定义注解、AOP切面、条件装配、自动配置等多项高级特性，是一个非常好的注解驱动开发能力的检验。

7. 常见问题深度排查与性能调优思考

7.1 Bean循环依赖的注解场景分析与解决

循环依赖是Spring面试的经典问题。在注解驱动下，主要通过三级缓存机制解决Setter/字段注入的循环依赖，但构造器注入的循环依赖无法解决。

三级缓存流程简述（针对单例Bean）：

第一级缓存（单例池）：singletonObjects，存放完全初始化好的Bean。
第二级缓存（早期暴露对象）：earlySingletonObjects，存放提前暴露的、尚未完成属性填充和初始化的Bean（用于解决循环依赖）。
第三级缓存（对象工厂）：singletonFactories，存放创建Bean的工厂ObjectFactory。

当发生A依赖B，B依赖A时：

开始创建A，实例化A（调用构造器），将A的ObjectFactory放入三级缓存。
为A进行属性填充，发现需要B，于是去获取B。
开始创建B，实例化B，将B的ObjectFactory放入三级缓存。
为B进行属性填充，发现需要A，于是去获取A。
从三级缓存中拿到A的ObjectFactory，调用getObject()方法。这个方法可能会返回A的原始对象，也可能返回A的代理对象（如果A需要被AOP代理）。此时将得到的A对象（可能是代理）放入二级缓存，并从三级缓存移除A的工厂。
B拿到A的引用（早期对象），完成属性填充和初始化，放入一级缓存。
A拿到B的引用（此时B已完全初始化），完成自己的属性填充和初始化，然后将自己放入一级缓存，并清理二级缓存。

注意事项：

构造器循环依赖无法解决：因为实例化A就需要B，而实例化B又需要A，在第一步就卡住了，对象都无法创建，更谈不上放入三级缓存。
原型（Prototype）作用域的Bean循环依赖无法解决：Spring不缓存原型Bean。
@Async、@Transactional等AOP代理的特殊情况：如果循环依赖的Bean中有此类代理，需要确保代理创建方式（CGLIB）能支持循环依赖。在Spring中，通常通过将@Async或@Transactional注解放在单独的类（或使用接口+JDK代理）来避免此类复杂情况。

7.2 注解扫描导致的启动性能优化

大型项目可能有数百个组件包，不当的@ComponentScan会导致启动变慢。

优化策略：

精确指定扫描路径：避免使用@ComponentScan（不指定basePackages）或@SpringBootApplication（默认扫描主类所在包及其子包）的默认行为。明确指定需要扫描的包。
```
@SpringBootApplication(scanBasePackages = {"com.example.service", "com.example.controller"})
```
使用过滤器排除：使用excludeFilters排除不需要的包或特定注解的类，特别是第三方库的自动扫描。
惰性初始化：对非关键路径的Bean使用@Lazy注解。这样Bean只有在第一次被请求时才会创建，可以加快应用启动速度。但要注意，这可能会将创建Bean的成本转移到第一次请求时，导致第一次请求变慢。
关注@Configuration的proxyBeanMethods：如前所述，对于无内部Bean方法调用的配置类，设置proxyBeanMethods = false可以减少CGLIB代理类的生成，提升启动性能。

7.3 自定义注解与元注解（Meta-annotation）的最佳实践

元注解是指被标注在其它注解定义上的注解。Spring大量使用元注解来组合功能，例如@Service本身就被@Component元标注。

创建组合注解：你可以创建自己的组合注解来简化配置。

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented @Service // 元标注，使其具备@Service的功能 @Transactional(readOnly = true) // 默认添加只读事务 @Scope("prototype") // 默认原型作用域 public @interface ReadOnlyService { // 可以添加自定义属性 String value() default ""; }

这样，你只需要使用@ReadOnlyService，就等于同时应用了@Service、@Transactional(readOnly=true)和@Scope(“prototype”)。

在注解中定义默认值：合理设置默认值可以让注解使用起来更简洁。例如，@Monitor(value=“defaultName”)，如果value是必须的，可以考虑将其设为默认属性（注解中名为value的属性可以省略属性名）。

处理注解的运行时信息：在切面或后置处理器中，可以通过JoinPoint或AnnotatedElement（Method,Class）获取注解及其属性值，实现动态逻辑。

三个月的时间，从梳理脉络、设计案例、调试源码到撰写成文，这个过程对我自己也是一次极致的重塑。我始终相信，对底层机制的理解深度，决定了你在应用层解决问题的能力上限。注解驱动开发不仅仅是“用注解代替XML”，它背后是一整套关于IoC容器生命周期、Bean定义处理、AOP织入、条件化装配的精致哲学。希望这个系列能像一束光，照亮你探索Spring源码的道路，让你在面对纷繁复杂的业务场景和诡异的技术问题时，能多一份从容与笃定。真正的“震撼”，不在于知识的堆砌，而在于思维模式的升级和那把能打开任意一扇技术之门的万能钥匙。

日记详情

Spring注解驱动开发深度解析：从原理到实战，彻底掌握IoC、AOP与条件装配