spring 容器在启动时会预先创建并初始化所有非懒加载的单例 bean，因此依赖类（如 a）的构造函数必然早于被依赖类（如 b、c）的构造函数执行，这是 spring 生命周期机制决定的。
spring 容器在启动时会预先创建并初始化所有非懒加载的单例 bean，因此依赖类（如 a）的构造函数必然早于被依赖类（如 b、c）的构造函数执行，这是 spring 生命周期机制决定的。
在 Spring 中，Bean 的创建与注入并非按 getBean() 调用顺序动态触发，而是由容器在 ApplicationContext 初始化阶段统一调度完成。以你的示例为例：
- A、B、C 均为 @Component 标注的普通组件，默认作用域为 singleton，且未启用 @Lazy；
- 当执行 new AnnotationConfigApplicationContext(LegendConfig.class) 时，Spring 容器启动，进入 预实例化（pre-instantiation）阶段；
- 容器扫描到 A、B、C 三个 Bean 定义后，会按依赖拓扑排序（Dependency Graph Topological Sort）确定创建顺序：先创建无依赖或依赖已就绪的 Bean；
- A 不依赖任何其他 Bean，因此最先被实例化（调用 A() 构造函数）；
- 接着创建 B：调用 B() 构造函数 → 此时 B 实例已存在，但属性 a 尚未赋值；
- 然后执行 B.setA(a)（@Autowired setter 注入）→ 此时 a 已是完全初始化好的 A 实例；
- 同理，C 的构造函数和 setA() 也在容器启动阶段完成（而非 getBean(C.class) 时才触发）。
✅ 关键点：applicationContext.getBean(B.class) 不创建新实例，仅从已构建完毕的单例池中返回引用；真正耗时的构造与注入过程，已在上下文刷新（refresh()）阶段全部完成。
你可以通过以下方式验证该行为：
@Configuration
@ComponentScan("com.spring.core.trialDI")
class LegendConfig {
@Bean(initMethod = "onInit")
public static class InitHook {
public void onInit() {
System.out.println("✅ All singleton beans initialized!");
}
}
}
输出将明确显示：I am A constructor! → I am B constructor! → I am setA of B! → I am C constructor! → I am setA of C! → ✅ All singleton beans initialized!，印证了“构造先行、注入随后、获取即得”的全流程。
⚠️ 注意事项：
- 若 A 本身依赖 B（形成循环依赖），且均使用构造器注入，则 Spring 无法解决，启动报 BeanCurrentlyInCreationException；
- Setter 注入（如本例）可借助 Spring 的三级缓存机制解耦创建与注入，支持部分循环依赖场景；
- 如需延迟初始化某 Bean，请显式添加 @Lazy 注解（作用于类或 @Bean 方法），此时其构造函数将在首次 getBean() 时才执行。
总之，理解 Spring 的“启动期批量预创建 + 按需获取”模型，是掌握依赖注入时序逻辑的核心前提。
