为何标注@Configurable与@ComponentScan的配置类未重复初始化Bean？

First, I assume you meant @Configuration instead of @Configurable here — @Configurable is a different annotation used for AspectJ-based dependency injection, not for defining Spring configuration classes. I’ll focus on @Configuration + @ComponentScan since that aligns with the quote you referenced.

Let’s start by breaking down the quote from Williams to clarify what’s being described:

@Configuration类本身也是@Component，因此若开启其所在包的组件扫描，配置类会被自动扫描到。这会带来预期和非预期的结果，若配置类对自身所在包开启组件扫描，Bean可能会被实例化两次，这是不利的。（Williams 346）

What this quote actually means #

Here’s a plain-language breakdown:

• @Configuration is a specialization of @Component — under the hood, Spring treats configuration classes as standard components. That means if you enable component scanning (@ComponentScan) that includes the package where your @Configuration class lives, Spring will pick up the configuration class as a regular component, in addition to processing it as a configuration class.
• The problem arises when this dual processing happens: normally, Spring uses a CGLIB proxy to enhance @Configuration classes. This proxy ensures that @Bean methods are only called once (so singleton beans stay true to Spring’s singleton guarantee). But if the configuration class is also picked up by component scanning, it gets instantiated as a plain @Component (no proxy). Now you have two instances of your configuration class:
  1. The enhanced proxy instance that Spring uses to manage bean definitions properly
  2. A plain, unproxied instance created by component scanning
• Both instances will execute their @Bean methods, leading to duplicate singleton beans — which breaks core Spring behavior and can cause bugs like inconsistent state or resource leaks.

Why you might not be seeing duplicate beans #

If your setup isn’t causing duplicates, here are the most likely explanations:

• Your @ComponentScan doesn’t include the configuration class’s package
  Maybe you specified basePackages or basePackageClasses that exclude the package where your configuration class resides. For example, if your config class is in com.app.config but you’re only scanning com.app.services, component scan won’t pick up the config class as a component.

• Modern Spring versions have built-in safeguards
  Newer versions of Spring (especially Spring Boot) detect this exact edge case and automatically prevent duplication. Spring will skip creating the plain @Component instance of the configuration class if it’s already being processed as a configuration class, keeping only the enhanced proxy version.

• You’re using @Configuration(proxyBeanMethods = false)
  When you set this attribute, Spring doesn’t create a CGLIB proxy for the configuration class (it’s treated as a "lite" config). In this case, even if component scan picks it up, there’s no proxy vs plain instance conflict — though this only avoids duplication if the configuration class isn’t being loaded through another mechanism (like @Import).

• Your configuration class is only loaded once
  If you’re not explicitly importing the configuration class (via @Import, XML, or another config class) and only relying on component scan, Spring will just create one instance (the plain component). Since it’s annotated with @Configuration, Spring will still process its @Bean methods — no duplication happens here because there’s only one instance to execute them.

内容的提问来源于stack exchange，提问作者katiex7