Spring Boot 中子类无法自动覆盖父类 setter 注入的 bean，需显式干预：在子类 setter 上加 @Autowired 和 @Qualifier 指定新 bean，或改用构造器注入，或通过 @Primary/@Profile 控制 bean 生效范围。
父类用 setter 注入依赖，子类继承后想覆盖容器中已绑定的 bean 实例——这在 Spring Boot 中不是自动发生的，需要明确干预。Spring 容器按类型或名称匹配注入，不会因为子类重写了 setter 方法就自动替换父类中注入的对象。关键在于：容器注入发生在 bean 初始化阶段，而 setter 覆盖只是 Java 方法重写，不改变容器的依赖解析逻辑。
父类 setter 注入的典型写法
父类声明依赖并提供可被 Spring 调用的 setter：
- 字段用 protected 或 package-private，便于子类访问
- setter 方法加 @Autowired（Spring 5.2+ 默认开启构造器注入优先，需显式标注才能启用 setter 注入）
- 避免在 setter 内直接 new 对象，否则会绕过 Spring 管理
示例：
public abstract class BaseService {protected UserService userService;
@Autowired
public void setUserService(UserService userService) {
this.userService = userService;
}
}
子类覆盖注入行为的三种可行方式
单纯重写 setter 方法（无注解、无逻辑）不会影响容器注入结果。真正生效的方式有以下几种：
-
在子类 setter 上重新加 @Autowired + @Qualifier：指定注入另一个具体 bean，如
@Qualifier("adminUserService") -
子类不依赖父类 setter，改用自身构造器注入：Spring 会优先调用子类构造器，跳过父类 setter；此时父类字段需设为
transient或用@Lazy避免冲突 - 通过 @Primary 或 @Profile 控制 bean 生效范围：让子类场景下容器只暴露一个匹配的 bean，自然覆盖父类注入目标
实操建议：推荐组合使用 @Qualifier + 自定义 Bean 名称
这是最清晰、低侵入、易测试的做法：
- 为不同业务场景定义多个 UserService 实现，如
NormalUserService和MockUserService - 在子类中显式指定要注入的实现：
@Autowired
public void setUserService(@Qualifier("mockUserService") UserService userService) {
super.setUserService(userService); // 可选：仍委托给父类字段
} - 确保配置类或启动类中确实注册了该名称的 bean，否则启动报错
NoUniqueBeanDefinitionException
常见误区与验证方法
容易误以为“子类重写 setter 就等于替换了注入源”，但实际运行时可能仍注入原 bean。验证是否生效：
- 在 setter 方法内打日志或断点，确认被调用的是子类版本
- 检查最终使用的 userService 实例的
getClass().getSimpleName() - 用
@PostConstruct在初始化后打印依赖对象，确认类型符合预期
