本文详解 spring boot 中因测试环境未启用 spring 上下文导致的依赖注入歧义问题：当工厂类同时注入 parentclass 和 childclass 时，mockito 默认按类型匹配而非 @qualifier 语义注入，造成父类变量实际持有子类实例。提供两种可靠修复方案——启用 spring 测试上下文或手动构造工厂实例。
本文详解 spring boot 中因测试环境未启用 spring 上下文导致的依赖注入歧义问题：当工厂类同时注入 parentclass 和 childclass 时，mockito 默认按类型匹配而非 @qualifier 语义注入，造成父类变量实际持有子类实例。提供两种可靠修复方案——启用 spring 测试上下文或手动构造工厂实例。
在 Spring Boot 应用中实现工厂设计模式时，一个常见陷阱是：看似正确的 @Qualifier 注入，在单元测试中却失效。根本原因在于——@InjectMocks（来自 Mockito）与 Spring 的依赖注入机制完全无关。它仅基于类型（Type）进行字段匹配注入，而忽略 @Qualifier("ParentClass") 等 Spring 特有元数据。由于 ChildClass 是 ParentClass 的子类，当 Mockito 扫描构造函数参数 ParentClass parentClass 时，它会将唯一可用的 @Mock 类型匹配对象（即 childClass 实例）注入进去——即使你声明了两个独立的 @Mock 字段，只要类型兼容，就会发生“子类覆盖父类引用”的静默错误。
✅ 正确方案一：启用 Spring 测试上下文（推荐用于集成验证）
使用 @SpringBootTest + @RunWith(SpringRunner.class)（Spring Boot 2.3+ 可简写为 @ExtendWith(SpringExtension.class)）启动完整 Spring 容器，让 @Qualifier、@Component 和依赖解析真正生效：
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.junit.jupiter.SpringExtension;
import static org.junit.jupiter.api.Assertions.assertEquals;
@ExtendWith(SpringExtension.class)
@SpringBootTest
class FactoryTest {
@Autowired
@Qualifier("ParentClass")
private ParentClass parentClass;
@Autowired
@Qualifier("ChildClass")
private ChildClass childClass;
@Autowired
private Factory factory;
@Test
void getObjectTest() {
// Spring 容器确保注入的是精确匹配的 Bean
assertEquals(parentClass, factory.getObject(true));
assertEquals(childClass, factory.getObject(false));
}
}⚠️ 注意事项：
- 此方式验证的是 真实 Spring 环境下的行为，适合端到端逻辑校验；
- 需确保
ParentClass和ChildClass的@Component("xxx")命名唯一且无冲突；- 若
ChildClass不应被直接注入（如仅作内部实现），建议将其移出组件扫描范围（例如不加@Component，改由工厂内部new或@Bean显式注册）。
✅ 正确方案二：纯 Mockito 测试 —— 手动构造工厂实例
若需轻量级单元测试（不启动 Spring 上下文），应完全绕过 @InjectMocks，改为显式传参构造工厂对象：
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.mockito.Mock;
import org.mockito.MockitoAnnotations;
import static org.junit.jupiter.api.Assertions.assertEquals;
class FactoryTest {
@Mock
private ParentClass parentClass;
@Mock
private ChildClass childClass;
private Factory factory;
@BeforeEach
void setUp() {
MockitoAnnotations.openMocks(this); // 初始化 Mocks
// 手动构造，精准控制依赖注入
factory = new Factory(parentClass, childClass);
}
@Test
void getObjectTest() {
assertEquals(parentClass, factory.getObject(true));
assertEquals(childClass, factory.getObject(false));
}
}? 关键点：
- 移除
@InjectMocks和@Mock的name属性（name="xxx"在此无效）；- 使用
MockitoAnnotations.openMocks(this)替代旧版@RunWith(MockitoJUnitRunner.class)；- 构造函数参数顺序必须与
Factory定义严格一致（ParentClass在前，ChildClass在后）。
? 根本规避建议：重构工厂设计
为彻底避免此类歧义，推荐更健壮的工厂实现方式：
-
使用
ObjectProvider<t></t>或ApplicationContext按名称获取 Bean（解耦注入时机）； -
将
ChildClass设为非@Component，仅在工厂内部通过new ChildClass()或@Bean方法创建； -
采用策略模式 +
@ConfigurationProperties绑定类型映射，提升可配置性与可测性。
总之，理解 “Mockito 不解析 Spring 注解” 是解决该问题的第一把钥匙。选择方案一验证生产行为，选择方案二保障单元测试速度与隔离性——二者皆可破局，关键在于明确测试目标与边界。
