Spring框架的核心是一套控制反转容器，它把应用程序中对象的创建、装配和生命周期管理从业务代码中抽离出来。传统写法里，Service依赖Repository时通常要在构造方法或字段上手动new一个具体实现，而Spring会扫描带有组件注解的类，把这些对象注册到容器，之后在需要的地方通过依赖注入自动完成关联。这种思路带来的最直接变化是，调用方不再关心实现类如何创建，只依赖接口即可。
IoC容器的工作方式与Bean生命周期
控制反转这个名字听起来抽象，实际上它描述的是对象控制权的转移。没有容器时，对象的创建时机由调用方决定；引入Spring后，创建权交给了容器。开发者只需要通过注解、XML或Java配置声明类之间的依赖关系，Spring启动时会解析这些元数据，生成BeanDefinition，再根据定义实例化对象并注入依赖。以常见的服务层代码为例：
// 传统方式：手动new依赖
UserRepository repository = new UserRepositoryImpl();
UserService service = new UserService(repository);
// Spring方式：使用构造器注入，容器负责装配
@Service
public class UserService {
private final UserRepository repository;
public UserService(UserRepository repository) {
this.repository = repository;
}
}
这段代码中，@Service注解让Spring扫描到UserService并创建Bean。当容器发现UserService构造器需要UserRepository时，会先去容器中查找或创建UserRepository实例，再完成注入。如果UserRepository是接口，容器会根据实际存在的实现类或者显式配置的@Primary、@Qualifier来确定具体注入哪一个。这种方式让单元测试变得简单：测试时可以传入Mock实现，而不用修改业务代码。
Bean的生命周期也是IoC容器的重要细节。一个Bean从创建到销毁通常经历实例化、属性填充、初始化、使用、销毁几个阶段。Spring提供了InitializingBean接口、@PostConstruct注解以及BeanPostProcessor回调，允许开发者在Bean初始化前后插入自定义逻辑。理解生命周期有助于解决启动时报错或Bean状态异常的问题。比如某些依赖外部资源的Bean需要在初始化阶段建立连接，销毁阶段释放资源，这些都可以通过生命周期回调实现。
容器管理Bean时默认采用单例模式，也就是一个Bean名称在整个容器中只有一个实例。这个默认值适合无状态的服务类，但如果Bean内部持有可变状态，就可能引发线程安全问题。可以使用@Scope注解把作用域改成prototype、request或session，但要谨慎，因为原型作用域下每次获取都会新建实例，如果注入到单例Bean中，容器不会每次都重新解析，容易产生隐藏错误。这个细节在后面常见问题部分会再次提到。
AOP的实现原理与典型应用
如果说IoC解决的是组件之间的耦合问题，AOP则负责处理横切关注点。日志、事务、权限校验这些逻辑散落在多个方法里，如果不加处理，会与业务代码混在一起，导致重复且难以维护。Spring的AOP通过代理对象拦截方法调用，把横切逻辑集中到切面中，在目标方法执行前、执行后或抛异常时动态织入。
底层的代理机制分为两种：如果目标类实现了接口，Spring默认使用JDK动态代理；如果目标类没有实现接口，则使用CGLIB生成子类代理。Spring Boot高版本中默认对代理策略做了调整，即使实现了接口也可能使用CGLIB，这一点在调试代理失效问题时需要了解。下面的示例展示了一个简单的切面，它会在Service层方法执行时输出日志：
@Aspect
@Component
public class LoggingAspect {
@Before("execution(* com.example.service..*.*(..))")
public void logBefore(JoinPoint joinPoint) {
String method = joinPoint.getSignature().getName();
System.out.println("调用方法：" + method);
}
}
这段代码里的@Aspect声明切面，@Before定义前置通知。execution表达式指定匹配的包路径和方法。除了前置通知，Spring还支持后置通知、返回通知、异常通知和环绕通知。环绕通知最灵活，可以控制是否继续执行目标方法，也可以修改返回值，但使用不当会吞掉异常或造成性能损耗。
AOP的典型应用场景包括声明式事务、操作日志采集、接口耗时统计、权限拦截等。以事务为例，Spring会在方法调用前开启事务，在方法正常返回时提交，在抛出运行时异常时回滚。这比在每个方法里手动写事务管理代码要简洁得多。不过AOP带来便利的同时也增加了理解成本，因为最终执行的是代理对象，this调用绕过代理会导致增强逻辑失效，这也是很多开发者第一次遇到事务失效时的原因之一。
Spring生态模块与实际项目应用
单独的Spring框架核心能力有限，真正的开发效率来自它上面的生态项目。Spring Boot通过自动配置简化了项目搭建，开发者只需要引入对应starter依赖，框架会根据classpath中的类自动创建DataSource、TransactionManager、Web服务器等组件，免去了大量XML配置。一个典型的Web服务启动类通常如下：
@SpringBootApplication
@RestController
public class DemoApplication {
public static void main(String[] args) {
SpringApplication.run(DemoApplication.class, args);
}
@GetMapping("/hello")
public String hello() {
return "Hello Spring";
}
}
@SpringBootApplication是一个组合注解，包含组件扫描、自动配置等多个能力。启动后内嵌的Tomcat会监听端口并提供HTTP服务，整个流程不需要手动部署WAR包。Spring MVC负责请求映射、参数绑定和返回值序列化，开发者写Controller方法就能对外提供接口。Spring Data则进一步简化数据访问，定义接口继承JpaRepository后，常见的增删改查方法不用写实现，框架会根据方法名自动生成查询。
在微服务架构中，Spring Cloud提供了服务注册与发现、配置中心、熔断降级、网关路由等组件。实际项目里经常使用Nacos或Eureka做服务治理，使用OpenFeign做跨服务调用，使用Sentinel或Resilience4j做限流。Spring Security负责认证和授权，支持表单登录、JWT、OAuth2等模式。这些模块的共同特点是约定优于配置，初学者按照官方文档引入依赖并添加少量配置就能跑通，但遇到自定义需求时还是需要理解底层自动配置类，否则一旦某个Bean冲突或自动配置不生效，排查起来会非常吃力。
实际工程中，我会优先使用Java配置类而不是XML来声明Bean，因为类型安全和重构更方便；同时把所有业务的Bean都交给Spring容器统一管理，但不会让容器管理线程池或连接池这类资源，它们的生命周期更复杂，通常由专门的配置类负责创建并注册。另外，建议将配置拆分成多个Profile，便于开发、测试、生产环境的切换，避免把环境相关配置写死在代码里。
长期使用感受、常见问题与注意事项
长期用Spring开发后，最明显的感觉是代码结构被约束得更加合理。依赖注入让类与类之间依赖接口而非具体实现，模块边界清晰，加上JUnit和Mockito配合，写单元测试的成本明显降低。同时Spring庞大的生态让大部分通用问题都有现成解决方案，不用重复造轮子。但代价是项目启动时间变长，很多自动配置在启动阶段完成，应用变得厚重；而且隐藏的默认行为很多，比如Bean默认单例、事务默认只在RuntimeException时回滚、AOP默认只对代理对象生效，这些默认值如果理解不到位，就容易埋下故障。
常见问题中，Bean循环依赖是比较典型的一类。构造器注入下A依赖B、B依赖A，Spring会直接抛出BeanCurrentlyInCreationException；字段注入依赖三级缓存可以部分解决，但不推荐依赖这个机制，因为代码结构上循环依赖往往意味着设计需要调整。事务失效也经常遇到，比如同类中方法自调用、目标方法不是public、异常被catch后没有抛出等，都会导致事务不生效。AOP失效同理，调用对象必须来自容器代理，如果直接new对象或通过this调用，增强逻辑不会执行。
使用注解配置Bean时，建议优先使用构造器注入而不是字段注入。构造器注入能让依赖不可变，避免空指针，也更容易发现循环依赖。对于@Value注入的配置项，最好配套使用@ConfigurationProperties绑定整个配置类，这样类型安全且支持校验。事务方法尽量放在独立的Service层，避免在Controller直接操作多个事务方法造成不可控。升级Spring Boot版本时，一定要查看官方迁移指南，因为自动配置类和默认依赖版本经常变化，老项目原地升级可能出现Bean冲突或启动失败。
性能方面，Spring框架本身对业务性能的影响通常不在框架本身，而在于不合理的Bean作用域、频繁的代理创建和过多的AOP拦截。如果接口耗时敏感，可以开启日志切面统计并监控，但避免在生产环境输出过多日志。另外注意不要把所有对象都交给容器，值对象、DTO、实体类等应该由业务代码直接创建，只有需要依赖注入的服务和组件才注册为Bean，这样能减少容器体积和启动时间。