1. 从XML到JavaConfig配置方式的演进与核心动机如果你是从Spring 2.x、3.x时代一路走过来的开发者一定对那个被XML配置文件支配的时代记忆犹新。一个中等规模的项目applicationContext.xml动辄几百行各种bean标签嵌套property和constructor-arg写得人眼花缭乱。那时候管理Bean的依赖关系就像在维护一张复杂的手绘地图一旦项目规模上去可读性和可维护性就成了大问题。后来为了简化注解驱动配置如Component,Autowired逐渐成为主流但很多核心配置如数据源、事务管理器、AOP依然离不开XML。直到Spring 3.0引入了JavaConfig我们才真正拥有了一个类型安全、易于重构、并且能与现代Java开发工具链IDE的代码补全、静态分析完美融合的配置方式。JavaConfig的核心思想很简单用Java类来定义和配置Spring容器中的Bean。它不是什么黑魔法本质上就是将原来写在XML文件里的那些Bean定义用Bean注解标注的方法来替代。这样做的好处是立竿见影的。首先它是强类型的。你在方法返回值里写DataSourceSpring就知道你要注册一个数据源BeanIDE能帮你做类型检查、方法跳转重构起来比如改名也比在XML里搜索字符串安全得多。其次它让配置逻辑变得可编程。你可以在Bean方法里写任何Java代码使用条件判断、循环、调用其他方法来动态决定如何创建Bean这是静态的XML文件难以做到的。最后它让配置和业务代码的边界更清晰。专门的配置类集中管理所有基础设施Bean业务类则专注于业务逻辑用Component等注解声明自己即可。所以当我们谈论JavaConfig时我们谈论的不仅仅是一个叫Configuration的注解而是一种更现代、更工程化、更“Java”的Spring应用组装方式。它代表了Spring框架自身从“配置即文档”向“配置即代码”的范式转变也是后续Spring Boot“约定大于配置”和自动配置得以实现的重要基石。理解JavaConfig是理解现代Spring应用架构的关键一步。2. Configuration与BeanJavaConfig的基石与运作原理JavaConfig的核心就是两个注解Configuration和Bean。它们的组合构成了Spring IoC容器在Java代码中的蓝图。Configuration声明这是一个配置类这个注解标注在类上它的核心作用是告诉Spring“这个类不是一个普通的Bean而是一个专门用来定义其他Bean的配置元数据源。” Spring容器在启动时会特别处理这些被Configuration标注的类。它会使用CGLIB库为这个类创建一个动态子类代理这个代理会拦截所有Bean方法的调用确保每次调用返回的都是Spring容器管理下的同一个单例Bean除非你指定了其他作用域。这就是为什么在Configuration类中你可以通过方法调用来注入Bean依赖而不用担心每次都创建一个新实例。Configuration public class AppConfig { // 这个类就是一个配置类 }Bean定义容器中的一个Bean这个注解标注在方法上。被它标注的方法其返回值将会被注册为Spring应用上下文中的一个Bean。Bean的名称默认是方法名你也可以通过Bean(“myBeanName”)来指定。Configuration public class DataSourceConfig { Bean public DataSource dataSource() { // 创建并配置一个DataSource实例 HikariDataSource ds new HikariDataSource(); ds.setJdbcUrl(jdbc:mysql://localhost:3306/mydb); ds.setUsername(root); ds.setPassword(password); ds.setMaximumPoolSize(10); return ds; // 这个返回的对象会被Spring容器接管 } Bean public PlatformTransactionManager transactionManager(DataSource dataSource) { // 方法参数 dataSource 会自动从容器中注入 return new DataSourceTransactionManager(dataSource); } }在上面的例子中dataSource()方法定义了一个DataSourceBean。transactionManager(DataSource dataSource)方法定义了一个事务管理器Bean并且它声明需要一个DataSource作为依赖。Spring会先创建dataSourceBean然后在创建transactionManagerBean时自动将已创建好的dataSourceBean注入进来。这个过程完全由Spring容器管理实现了依赖注入。与Component/Service等注解的对比这是一个常见的困惑点。Component、Service、Repository、Controller这些是类级别的注解用于声明一个类本身是需要被Spring扫描并实例化为Bean的。它们属于“组件扫描”的范畴。通常我们用它来标记我们自己的业务逻辑类。而Bean是方法级别的注解用于在配置类中显式地定义一个Bean。它通常用于配置第三方库的类因为这些类的源码我们无法修改不能加Component。需要复杂初始化逻辑的Bean比如上面DataSource的配置。需要根据条件动态创建的Bean。简单来说Component等是“声明我自己是一个Bean”而Bean是“我配置类来告诉Spring如何创建一个Bean”。在实际项目中两者常常结合使用自己的服务类用Service而数据源、缓存客户端、RestTemplate等基础设施用Bean在配置类中定义。3. 依赖注入的三种姿势在Bean方法中实现IoC在XML配置中我们通过property ref...或constructor-arg ref...来声明依赖。在JavaConfig中依赖注入变得更加直观和类型安全主要有以下三种方式。3.1 方法参数注入最常用、最推荐这是最简洁、最直接的方式。直接在Bean方法的形式参数中声明你所依赖的BeanSpring会自动将容器中匹配类型的Bean注入进来。Configuration public class ServiceConfig { Bean public MyRepository myRepository() { return new JdbcMyRepository(); } Bean public MyService myService(MyRepository myRepository) { // myRepository 参数由Spring自动注入 return new MyServiceImpl(myRepository); } }为什么推荐这种方式意图清晰一眼就能看出MyService依赖MyRepository。易于测试在单元测试中你可以直接调用myService()方法并传入一个Mock的MyRepository而不需要启动整个Spring容器。避免循环依赖如果存在循环依赖A依赖BB也依赖ASpring在启动时通过方法参数注入能更早地发现问题。3.2 方法调用注入仅在Configuration类内部使用在同一个Configuration类内部你可以直接调用另一个Bean方法来获取依赖。这看起来非常直观就像普通的Java方法调用一样。Configuration public class DirectCallConfig { Bean public DataSource dataSource() { // 创建DataSource return new HikariDataSource(...); } Bean public PlatformTransactionManager transactionManager() { // 直接调用 dataSource() 方法 return new DataSourceTransactionManager(dataSource()); } }这里有一个至关重要的细节由于Configuration类会被CGLIB代理上面代码中对dataSource()的调用并不会真的执行原始方法体去创建一个新的HikariDataSource实例。相反代理会拦截这次调用直接返回Spring容器中已经创建好的那个单例DataSourceBean。所以这种方式是安全的并且是单例的。注意如果DirectCallConfig类没有被Configuration注解比如被Component注解那么dataSource()就是一个普通方法每次调用transactionManager()时都会执行一次dataSource()方法导致创建多个DataSource实例这通常不是我们想要的。因此方法调用注入这种方式务必确保在Configuration注解的类中使用。3.3 Autowired字段/Setter注入在配置类中较少使用你也可以在配置类中使用Autowired来注入依赖然后在Bean方法中使用这些被注入的字段。Configuration public class AutowiredConfig { Autowired private MyRepository myRepository; Bean public MyService myService() { return new MyServiceImpl(myRepository); } }这种方式可行但通常不推荐作为配置类中的首选。原因在于隐藏了依赖MyService的依赖关系没有显式地声明在myService()方法签名上降低了代码的可读性和可测试性。字段注入的固有缺点它让类变得不易于进行单元测试你需要通过反射来设置私有字段并且掩盖了“类需要哪些依赖才能正常工作”的设计意图。在大多数场景下方法参数注入是JavaConfig中实现依赖注入的最佳实践。它明确、安全且易于测试。4. 高级特性与实战技巧让配置更强大、更灵活掌握了基础之后JavaConfig还有一些高级特性能让你的配置如虎添翼应对更复杂的场景。4.1 条件化配置Conditional及其衍生注解这是JavaConfig相比XML最大的优势之一你可以根据环境、类路径、属性值等条件动态地决定是否要注册某个Bean。Spring Boot的自动配置就大量使用了此特性。ConditionalOnClass当类路径下存在指定的类时才生效。Configuration public class CacheConfig { Bean ConditionalOnClass(name com.github.benmanes.caffeine.cache.Caffeine) public CacheManager caffeineCacheManager() { // 只有项目中引入了Caffeine依赖这个Bean才会被创建 return new CaffeineCacheManager(); } }ConditionalOnMissingBean当容器中不存在指定类型或名称的Bean时才生效。这是实现“默认配置”和“用户自定义配置覆盖”的关键。Configuration public class DefaultMessageConfig { Bean ConditionalOnMissingBean // 如果用户自己定义了一个MessageService Bean这个默认的就不会生效 public MessageService messageService() { return new DefaultMessageService(); } }ConditionalOnProperty当指定的配置属性满足条件时才生效。Bean ConditionalOnProperty(prefix app.feature, name advanced-mode, havingValue true) public AdvancedService advancedService() { // 仅当 app.feature.advanced-modetrue 时才创建这个高级服务 return new AdvancedService(); }自定义Conditional你可以实现Condition接口编写最复杂的判断逻辑。public class MyCustomCondition implements Condition { Override public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) { // 可以从context中获取环境、资源加载器、Bean工厂等信息进行判断 String os context.getEnvironment().getProperty(os.name); return os ! null os.contains(Linux); } } // 使用 Bean Conditional(MyCustomCondition.class) public LinuxSpecificService linuxService() { ... }4.2 配置的模块化与导入Import当配置变得复杂时将所有Bean定义放在一个类里会非常臃肿。Import注解允许你将配置分散到多个类中提高可维护性。// DatabaseConfig.java Configuration public class DatabaseConfig { Bean public DataSource dataSource() { ... } Bean public JdbcTemplate jdbcTemplate(DataSource ds) { ... } } // CacheConfig.java Configuration public class CacheConfig { Bean public CacheManager cacheManager() { ... } } // 主配置类导入其他配置 Configuration Import({DatabaseConfig.class, CacheConfig.class}) public class AppConfig { // 可以在这里定义核心的、或需要引用上述模块Bean的配置 Bean public MyAppService myAppService(JdbcTemplate jdbcTemplate, CacheManager cacheManager) { return new MyAppService(jdbcTemplate, cacheManager); } }使用Import时被导入的配置类中定义的Bean完全等同于在主配置类中定义可以直接通过方法参数注入等方式引用。4.3 处理外部配置PropertySource与Value / Environment配置类当然需要读取外部属性如.properties或.yml文件。PropertySource指定属性文件的位置。Configuration PropertySource(classpath:database.properties) PropertySource(value file:/etc/app/config.properties, ignoreResourceNotFound true) public class PropertyConfig { // ... }使用Value注入单个属性Bean public DataSource dataSource( Value(${db.url}) String url, Value(${db.username}) String username, Value(${db.password}) String password) { // ... }通过Environment接口访问更灵活Configuration public class ConfigUsingEnv { Autowired private Environment env; Bean public SomeBean someBean() { String value env.getProperty(some.key, defaultValue); // 还可以检查属性是否存在、解析列表等 return new SomeBean(value); } }4.4 Bean的作用域、生命周期与别名作用域 (Scope)默认是单例singleton。你可以通过Scope注解更改。Bean Scope(prototype) // 每次注入或getBean()时都创建一个新实例 public PrototypeBean prototypeBean() { return new PrototypeBean(); } Bean Scope(value WebApplicationContext.SCOPE_REQUEST, proxyMode ScopedProxyMode.TARGET_CLASS) public RequestScopedBean requestScopedBean() { return new RequestScopedBean(); }对于request、session等作用域通常需要设置proxyMode因为配置类在容器启动时就被初始化了而request那时还不存在需要通过代理来延迟获取真正的Bean。生命周期方法Bean注解支持initMethod和destroyMethod属性指定初始化后和销毁前调用的方法名。Bean(initMethod init, destroyMethod close) public ExpensiveResource expensiveResource() { return new ExpensiveResource(); }更现代的方式是让Bean实现InitializingBean,DisposableBean接口或者使用JSR-250的PostConstruct和PreDestroy注解。Bean别名 (Bean(name {...}))一个Bean可以有多个名字。Bean(name {dataSource, primaryDataSource}) public DataSource dataSource() { ... }5. 从JavaConfig到Spring Boot自动配置的桥梁与最佳实践JavaConfig是Spring Boot“约定大于配置”和自动配置得以实现的基石。Spring Boot的自动配置本质上就是一系列条件化Conditional的JavaConfig配置类。例如当你的类路径下有HikariCP库时Spring Boot的DataSourceAutoConfiguration可能会提供一个默认的HikariDataSourceBean。这个自动配置类就是用一个Configuration类加上一堆ConditionalOnXxx注解实现的。在Spring Boot项目中使用JavaConfig的最佳实践主配置类通常使用SpringBootApplication注解的类它本身包含了Configuration作为主配置入口。你可以直接在里面定义Bean。专用配置类对于数据库、缓存、安全、Swagger等不同模块的配置建议创建独立的Configuration类并使用ConfigurationProperties来绑定一组配置属性使配置更清晰。Configuration EnableConfigurationProperties(DatabaseProperties.class) // 绑定属性类 public class DatabaseAutoConfig { private final DatabaseProperties properties; public DatabaseAutoConfig(DatabaseProperties properties) { this.properties properties; } Bean ConditionalOnMissingBean public DataSource dataSource() { HikariDataSource ds new HikariDataSource(); ds.setJdbcUrl(properties.getUrl()); // ... 使用properties中的值 return ds; } }覆盖自动配置如果你想覆盖Spring Boot的某个自动配置Bean只需要在你自己的Configuration类中定义一个同类型或同名称的Bean即可。因为Spring Boot的自动配置类大多使用了ConditionalOnMissingBean你的Bean定义后它的就不会生效了。配置的优先级理解配置源的优先级命令行参数 Java系统属性 操作系统环境变量 应用外的配置文件 应用内的配置文件 默认配置对于调试配置问题非常重要。JavaConfig中定义的Bean是代码层面的配置其属性值可以通过Value或Environment从高优先级的配置源获取。一个常见的坑配置类加载顺序有时你可能会遇到因为配置类加载顺序导致的BeanCurrentlyInCreationException循环依赖或某些Bean过早初始化的问题。你可以使用DependsOn注解来显式指定Bean的创建顺序或者使用AutoConfigureAfter、AutoConfigureBeforeSpring Boot特有来调整自动配置类的顺序。但更根本的解决方法是重新审视设计避免复杂的循环依赖。在我多年的Spring项目实践中JavaConfig彻底改变了管理应用依赖的方式。它让配置变得可读、可测试、可维护。我的建议是在新项目中毫不犹豫地全面采用JavaConfig并善用条件化注解来构建适应不同环境的、健壮的配置。对于老项目可以逐步将关键的XML配置片段迁移到JavaConfig中你会发现代码的掌控感会得到显著提升。记住好的配置代码和业务代码一样是项目质量的体现。