Spring_IOC

如果说 Spring 是一个拥有无数插槽、遵循统一电气标准的巨大插座，那么 MyBatis-Spring 就是一个设计精巧、完美适配的插头。

实践中，大量线上事故的根源并非对框架原理的不理解，而是那些重复出现的错误用法与设计误区——灵活性被滥用时，Spring 反而会成为故障的放大器。

本文将视角从“术”升维至“道”——提炼支撑 Spring 框架灵活、健壮、高度可扩展的二十余种设计模式，揭示其架构设计的思想骨架。

本文是核心容器系列的收官之作。将焦点从“如何正确使用”转移到“如何避免错误、快速排错”。 读完本文,将获得一份随身的“排错宝典”和一张“反模式速查表”,建立起对 Spring 核心容器的免疫系统。

在 XML 配置、@Value 注解或 Web 请求参数中，我们提供给 Spring 的几乎永远是字符串。那么，这些字符串是如何精准地变成 int、long、Date、List<User>等

从基于通用 SPI 的集中式清单管理，迈向基于专用接口的声明式按需组合。 本文将带你深入这两种机制的实现细节，剖析其背后的设计权衡，助你在自定义 Starter 开发或排查自动配置问题时，从“知其然”

@Import 是 Spring 模块化集成的万能钥匙。它就像一个 USB-C 接口——任何外部设备（第三方框架）只要遵循这个接口规范，就能即插即用地融入 Spring 生态。

系统地梳理这些扩展点的全貌，并给出大量实际应用举例，帮助你从“使用者”进阶为“定制者”，在需要时能够精准地选择正确的接口，对框架行为进行优雅地干预。

SpEL 作为 Spring 官方内嵌的表达式引擎，不仅支撑了 @Value、@Cacheable、@PreAuthorize 等无数注解背后的动态求值，还允许我们在运行时对 Bean 对象图进行查询

循环依赖并非单纯的“缓存结构”考题，其本质是对 Spring Bean 生命周期管理粒度的极限考验：容器在“实例化”与“完全就绪”两个状态之间，必须预留一个可供外界引用的“中间态”窗口，而三级缓存正是

以AOP 知识基座为起点，展示 AOP 的能力如何被赋予具体功能——它将不再是“日志打印”这样的简单切面，而是需要精确控制传播、回滚与资源清理的事务管理器调用链。

Spring AOP 的能力天花板——自调用失效的根源、切点表达式的性能陷阱，并引入 AspectJ 这一强大的盟友，特别是通过加载期织入（Load-Time Weaving, LTW）

AOP 是面向对象编程的有力补充，它将散布在应用各处的横切关注点（日志、事务、安全等）模块化为切面，从而消除代码冗余。

概述 衔接前文 在前两篇文章中，我们构建了 IoC 容器的完整设计蓝图：容器底层如何承载 BeanDefinition，配置元信息如何演化成 Bean 的骨架；接着我们遍历了 Bean 从扫描、实例化

每一个由 Spring 管理的 Bean——无论是一个 @Service、一个 @Controller，还是一条数据源连接——都必须经历从定义、创建、装配、初始化到最终销毁的严格旅程。

控制反转是现代软件架构的基石之一，它重新定义了组件间的依赖关系和生命周期管理方式。Spring IoC 容器正是这一理念最成功的工程化实现

ConfigFileApplicationListener 加载到 Spring 容器中的时机及流程

Spring Boot 中 application.yaml 的加载原理涉及环境初始化、配置文件定位、解析及属性绑定等多个步骤。

Spring通过三级缓存解决单例Bean的循环依赖（属性注入），但构造器注入和原型Bean无法处理，需避免或使用@Lazy延迟加载。 Spring循环依赖详解 1. 循环依赖的产生场景 当两个或多个B

pring 的依赖注入（Dependency Injection, DI）是其核心特性之一，通过将对象依赖关系的创建和管理交给容器，实现松耦合和高扩展性。