当使用 @Profile 控制 Bean 注册时，若测试类未显式激活对应 profile，Spring 可能复用前序测试遗留的上下文，导致 Bean 注册混乱、注入失败或跳过预期逻辑，引发单测通过但批量运行失败的问题。
当使用 `@profile` 控制 bean 注册时，若测试类未显式激活对应 profile，spring 可能复用前序测试遗留的上下文，导致 bean 注册混乱、注入失败或跳过预期逻辑，引发单测通过但批量运行失败的问题。
在 Spring 测试中，@Profile 是一个常见但极易误用的配置手段。你遇到的现象——单个测试方法通过，而整个测试目录运行时失败（甚至断点不触发）——本质上源于 Spring 的测试上下文缓存机制与 @Profile 的非隔离性设计之间的冲突。
? 问题根源分析
Spring Test 默认对相同配置的测试类复用 ApplicationContext（即上下文缓存），以提升执行效率。但 @Profile("test") 并非“测试专属开关”，它仅声明该 Bean 属于某个环境配置；若多个测试类分别依赖不同 profile（如 @Profile("test") 和 @Profile("!test")），且未统一显式指定激活 profile，Spring 会依据最先加载的配置类决定上下文内容，并将该上下文缓存供后续测试复用。
在你的案例中：
- TestConfig 声明了 @Profile("test") 的 B Bean；
- ProductionConfig 声明了 @Profile("!test") 的 A Bean；
- ATest 继承 TestConfig，但未声明 @ActiveProfiles("test")；
- 当单独运行 ATest 时，上下文首次创建，"test" profile 被隐式激活（因 TestConfig 显式标注），B 成功注册并注入；
- 当整目录运行时，若前置测试（如某 @ActiveProfiles("dev") 的测试）先启动了上下文，且该上下文未包含 "test" profile，则 TestConfig 被忽略，B Bean 根本不会注册——此时 @Autowired private B b 将因类型不匹配或缺失 Bean 而注入失败（可能静默为 null 或抛出异常），导致断点不命中、断言失败。
⚠️ 注意：@Profile("!test") 具有全局排他性，一旦任意测试激活了 "test"，ProductionConfig 中的 A 就会被排除，进一步加剧上下文状态不可预测性。
✅ 正确解法：用 @ConditionalOnProperty 替代 @Profile
@Profile 的设计初衷是区分部署环境（如 dev/prod/staging），而非控制测试逻辑。更安全、更语义清晰的做法是使用条件化配置注解，例如 @ConditionalOnProperty：
@Configuration
public class TestConfig {
@Bean
@ConditionalOnProperty(name = "app.test.mode", havingValue = "enabled", matchIfMissing = false)
public B b() {
return new B();
}
}并在测试类中通过 @TestConfiguration + 显式属性启用：
@SpringBootTest(properties = "app.test.mode=enabled")
class ATest {
@Autowired
private B b;
@Test
void test() {
assertThat(b.returnSth()).isEqualTo("b");
}
}或者，在 @SpringBootTest 中统一指定：
@SpringBootTest(properties = "app.test.mode=enabled")
class ATest { /* ... */ }?️ 最佳实践建议
- 永远显式声明激活的 profile：在测试类上添加 @ActiveProfiles("test")，避免依赖隐式行为；
- 避免 @Profile("!xxx")：它破坏配置可组合性，推荐用正向命名（如 @Profile("test") + @Profile("production")）并明确激活；
- 优先使用 @ConditionalOn... 系列注解：如 @ConditionalOnProperty、@ConditionalOnClass、@ConditionalOnMissingBean，它们基于具体条件判断，无环境耦合，测试隔离性更强；
- 必要时禁用上下文缓存：对高度敏感的测试，可加 @DirtiesContext 强制重建上下文（但会降低性能，慎用）。
通过将环境配置逻辑与测试控制逻辑解耦，你能彻底规避上下文污染问题，让每个测试真正“按需加载”，稳定可靠地运行于任何执行粒度下。
