1. Configuration与Component注解的本质区别在Spring框架中Configuration和Component都是核心注解但它们的职责和使用场景有本质差异。Configuration是Spring 3.0引入的注解用于显式声明一个类为配置类其内部包含Bean方法定义。而Component是更通用的注解用于标识一个类为Spring组件会被自动扫描并纳入IoC容器管理。1.1 核心功能对比特性ConfigurationComponent主要用途定义Spring配置类通用组件标识内部方法处理通过CGLIB代理保证单例普通方法调用Bean方法互调保证返回同一实例每次调用创建新实例扫描机制需显式声明或通过ComponentScan被ComponentScan自动发现典型应用场景数据源配置、第三方库集成Service、Repository层组件关键理解Configuration类中的Bean方法会被Spring特殊处理通过代理机制确保多次调用返回同一实例而Component类中的Bean方法则没有这种特性。2. Configuration的深层工作机制2.1 CGLIB代理原理当Spring容器处理Configuration类时会通过CGLIB生成子类代理。以下是一个典型配置类的字节码增强过程// 原始配置类 Configuration public class AppConfig { Bean public DataSource dataSource() { return new HikariDataSource(); } } // Spring处理后实际使用的代理类 public class AppConfig$$EnhancerBySpringCGLIB extends AppConfig { private DataSource cachedDataSource; Override public DataSource dataSource() { if (cachedDataSource null) { cachedDataSource super.dataSource(); } return cachedDataSource; } }这种机制保证了跨Bean方法的依赖注入时保持单例避免重复创建昂贵资源支持配置类之间的方法调用2.2 轻量级模式Lite Mode通过设置proxyBeanMethodsfalse可以禁用CGLIB代理Configuration(proxyBeanMethods false) public class LiteConfig { Bean public ServiceA serviceA() { return new ServiceA(serviceB()); // 每次调用都新建实例 } Bean public ServiceB serviceB() { return new ServiceB(); } }适用场景不需要跨Bean方法引用追求启动速度优化配置类没有状态依赖3. Component的典型应用场景3.1 组件扫描与自动装配Component及其衍生注解Service, Repository等构成了Spring的组件扫描基础Component public class OrderService { Autowired private PaymentService paymentService; public void process(Order order) { paymentService.charge(order); } }最佳实践保持组件无状态避免在Component类中定义Bean方法使用接口隔离原则3.2 与Bean的非常规组合虽然不推荐但在Component类中也可以使用BeanComponent public class SpecialConfig { Bean public SpecialBean specialBean() { return new SpecialBean(); } }这种用法的问题无法保证specialBean()的单例性方法互调会创建新实例违背关注点分离原则4. 高级配置技巧4.1 条件化配置结合Conditional系列注解实现灵活配置Configuration public class EnvConfig { Bean ConditionalOnProperty(name cache.enabled, havingValue true) public CacheManager redisCache() { return new RedisCacheManager(); } Bean ConditionalOnMissingBean(CacheManager.class) public CacheManager simpleCache() { return new SimpleCacheManager(); } }4.2 配置类组织策略按功能模块拆分├── config │ ├── DataSourceConfig.java │ ├── WebConfig.java │ └── SecurityConfig.java使用Import组合配置Configuration Import({DataSourceConfig.class, WebConfig.class}) public class MainConfig { // 主配置 }环境隔离配置Profile(dev) Configuration public class DevConfig { Bean public DataSource devDataSource() { // 开发环境数据源 } }5. 常见问题排查5.1 配置未生效问题症状Bean定义的组件没有被创建排查步骤检查配置类是否被ComponentScan扫描到确认是否缺少Configuration注解查看是否有Conditional条件不满足检查是否存在多个同类型Bean导致冲突5.2 循环依赖问题典型错误Configuration public class CircularConfig { Bean public A a(B b) { return new A(b); } Bean public B b(A a) { return new B(a); } // 循环依赖 }解决方案重构设计打破循环使用setter注入替代构造器注入添加Lazy延迟初始化5.3 代理失效问题当看到以下日志时需要警惕WARN o.s.c.a.ConfigurationClassEnhancer - Cannot enhance Configuration bean definition problemConfig because it is not eligible for enhancement...可能原因配置类被声明为final配置类中存在private方法使用了AspectJ编译时织入6. 性能优化建议将不变的配置设为lite模式Configuration(proxyBeanMethods false) public class StaticConfig { // 不变的基础设施配置 }合理规划组件扫描路径ComponentScan(com.service) Configuration public class OptimizedScanConfig { // 避免全包扫描 }延迟初始化配置Bean Lazy public ExpensiveBean expensiveBean() { return new ExpensiveBean(); }在实际项目中我通常会建立这样的配置类组织结构src/main/java └── com └── example ├── config │ ├── CoreConfig.java // 核心基础设施 │ ├── WebConfig.java // Web相关配置 │ └── EnvConfig.java // 环境相关配置 └── Application.java // 主启动类这种结构既保持了配置的模块化又避免了单个配置类过于臃肿。对于微服务项目建议每个服务模块都有自己的配置包通过ImportResource可以整合XML配置逐步迁移到全注解配置。