面经策

@Qualifier 注解有什么作用 ​

  • 标签：后端、Spring

🏛 业务架构师 ​

@Qualifier 的作用是在按类型自动装配出现多个候选 Bean 时，进一步按限定符精确指定注入哪一个。

典型业务场景：一个接口有多个实现——短信服务有阿里云、腾讯云两个 Bean，@Autowired 按类型注入时 Spring 无法裁决，启动即抛 NoUniqueBeanDefinitionException。解法：

java
public SmsService(@Qualifier("tencentSms") SmsService sms) { ... }

或给实现类打自定义限定注解，语义更清晰。

架构师视角，我把它放在**"多实现的治理策略"**里讲，因为有比裸用 @Qualifier 更好的工程实践：

  1. 优先 @Primary：多数请求走主实现、备用实现低频时，标主实现最省心；
  2. 策略模式显式路由：多渠道并存的业务（支付、推送、存储），注入 Map<String, Channel>，用渠道编码路由——业务开关、灰度切换在配置中心改一个 key 就生效，比散落各处的 @Qualifier 好运营；
  3. 自定义限定注解：如 @OfflineChannel，比字符串名更具业务语义，重构安全。

一句话：@Qualifier 是解决歧义的工具，但出现大量 @Qualifier 往往说明路由策略应该被显式建模——把它当信号，而不只是当扳手。

🏗 系统架构师 ​

作用：byType 出现多个候选 Bean 时，用限定符精确指定注入目标。

  • 基本用法：@Qualifier("redisCacheManager") 按 Bean 名称收窄；
  • 进阶：自定义注解（本身标注 @Qualifier）做语义分组——比如用 @Hot/@Cold 区分数据源、@PayChannel 区分支付实现，注入处声明意图而非实现名；
  • 与 @Primary 分工：Primary 定「全局默认」，Qualifier 定「本次特指」——默认走主实现，个别注入点点名切换。

架构视角：多实现歧义是集成接缝上最脆弱的点。我的治理规则：一个类型出现第二个实现时，必须同时补 Qualifier/Primary，并用 contextLoads 冒烟测试在 CI 阶段把 NoSuchBeanDefinition、NoUniqueBeanDefinition 拦在合并前。注解虽小，背后是装配确定性问题——确定性丢失的代价都在生产环境结算。

💻 全栈开发专家 ​

作用：同类型 Bean 有多个候选时，精确指定注入哪一个，消除 NoUniqueBeanDefinitionException。三种用法：

java
@Autowired
@Qualifier("mysqlOrderRepo")    // 1. 按 Bean 名指定
private OrderRepository repo;

// 2. 给实现类打"标签"（标在类上，注入点同名引用）
@Qualifier("payChannel")
@Component
public class PayChannelA implements Channel { }

// 3. 自定义限定注解（多维度路由最有用）
@Target({ElementType.FIELD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier
public @interface OfflineChannel { }

自定义 qualifier 注解是我做多数据源/多渠道路由的惯用手法：不同实现打 @OnlineChannel/@OfflineChannel 语义标签，注入点按语义选，重构改名不受 Bean 名称牵连。

优先级关系：@Qualifier 精确匹配 > @Primary 默认值 > 参数名匹配。分工上，@Primary 是"这堆里默认给这个"，@Qualifier 是"我就要那个"。依赖关系固定的场合用 qualifier，批量分发的场合还是 Map<String, T> 注入更清爽。