为何在src/test中优先使用@TestConfiguration而非@Configuration？

我正在深入学习@TestConfiguration，疑惑为何要采用如下组合：

@TestConfiguration
public class TestConfig {
    
    // some bean definitions 
}

再搭配使用：

@SpringBootTest
@Import(TestConfig.class)
class UsingImport {

    @Autowired
    ConfigBean configBean;

    // some code 
}

而非在src/test中使用原本合法的传统@Configuration。请问@TestConfiguration的真正用途是什么？我的理解是否有误？

核心区别与@TestConfiguration的价值 #

@TestConfiguration是Spring Boot专为测试场景设计的配置注解，它和普通@Configuration的核心差异，以及解决的痛点如下：

• 避免自动扫描的意外加载
  普通@Configuration如果放在src/test目录下，一旦主应用的组件扫描（比如@SpringBootApplication自带的扫描）覆盖到测试目录，这个配置类会被自动加载到主应用上下文，可能导致生产环境的bean被测试bean意外覆盖，或者测试配置干扰其他测试。而@TestConfiguration默认不会被组件扫描自动识别，必须通过@Import、@ContextConfiguration等方式显式引入，完全由开发者控制加载时机。

• 明确的测试语义标识
  标注@TestConfiguration的类，一眼就能看出是测试专属配置，和主应用的业务配置划清界限，避免代码维护时的混淆。比如团队新人看到这个注解，就知道这是给测试用的，不会误把它当成生产配置修改。

• 更灵活的测试上下文定制
  配合@SpringBootTest使用时，@TestConfiguration可以精准地给当前测试补充或替换bean，而不会影响其他测试的上下文。比如你有多个测试类，每个需要不同的mock bean，用@TestConfiguration + @Import可以实现每个测试的上下文独立，而普通@Configuration如果被扫描到，可能会被多个测试共享，导致测试之间的依赖污染。

关于你的理解误区 #

不是不能在src/test里用@Configuration，而是@TestConfiguration更适配测试场景的需求。如果你的测试配置不需要被多个测试共享，或者想严格控制配置的加载范围，@TestConfiguration是更优的选择；如果你的测试配置需要被所有测试自动加载，那普通@Configuration也可以用，但要注意组件扫描的范围，避免影响主应用。

内容的提问来源于stack exchange，提问作者work-in-progress