一个接口有多个实现类，Spring 注入时怎么选？@Primary、@Qualifier、集合注入怎么用？

简化版

当一个接口有多个实现类（多个候选 Bean）时，@Autowired byType 注入会「不知道选哪个」而报错（NoUniqueBeanDefinitionException）。Spring 提供了几种「消歧」手段：① @Primary——在某个实现类上标 @Primary，把它设为「首选」，没有更明确指定时就用它（一个类型只能有一个 @Primary）；② @Qualifier("beanName")——在注入点用 @Qualifier 指定要注入哪个 Bean（按名字/限定符精确选择），比 @Primary 优先级高；③ 按字段名匹配——@Autowired 找不到唯一 byType 时，会退化用「字段名/参数名」当 Bean 名去匹配（如字段叫 orderServiceImpl 就找名为 orderServiceImpl 的 Bean）；④ 集合注入——如果就是想要「所有实现」，可以注入 List<接口> 或 Map<String, 接口>（Map 的 key 是 Bean 名），Spring 把所有实现都注进来（常用于「策略模式」：一堆处理器全收集起来按需分发）。优先级：@Qualifier（精确指定）> @Primary（默认首选）> 字段名匹配。

详细版

消歧手段对比：

手段	用在哪	语义	优先级
`@Primary`	实现类上	设为「默认首选」	低（兜底默认）
`@Qualifier("x")`	注入点	精确指定某个 Bean	高（明确指定）
字段名匹配	自动	byType 不唯一时用字段名当 Bean 名	中
`List<T>` 注入	注入点	注入所有实现（有序，可 @Order）	—
`Map<String,T>`	注入点	注入所有实现（key=Bean 名）	—

public interface PayService { void pay(); }

@Service @Primary                        // 设为默认首选
public class AliPayService implements PayService { }
@Service
public class WechatPayService implements PayService { }

// ① 不指定 → 用 @Primary 的 AliPayService
@Autowired private PayService payService;

// ② @Qualifier 精确指定 → 用 WechatPayService（优先级高于 @Primary）
@Autowired @Qualifier("wechatPayService")
private PayService wechatPay;

// ③ 集合注入：拿到所有实现（策略模式）
@Autowired private List<PayService> allPayServices;         // 所有实现
@Autowired private Map<String, PayService> payServiceMap;   // key=Bean名→实现

⚠️ 集合注入（List/Map）是「策略模式」的最佳拍档，也是这几个手段里最容易被低估的一个。当你有「一族做同一类事的实现」（各种支付方式、各种消息处理器、各种导出格式），与其用一堆 if-else 判断类型，不如注入 Map<String, Handler>，用「类型 → Handler」的方式直接查表分发。Map 的 key 默认是 Bean 名，也可以让每个 Handler 自报「我处理什么类型」，构建成「业务类型 → Handler」的映射。这样加一个新实现只需加一个 @Component 类，分发逻辑一行不改（开闭原则）——这是 Spring 里消除 if-else、实现可扩展策略的经典套路。

完整版教学

一、问题：多个候选 Bean 的歧义

先理解问题——@Autowired 默认 byType，多个实现就歧义了：

@Autowired 默认按"类型"注入（byType）：
  @Autowired PayService payService;
  → 找类型是 PayService 的 Bean

如果 PayService 只有一个实现 → 直接注入，没问题
如果有多个实现（AliPay、WechatPay 都是 PayService）：
  → Spring 不知道该注入哪个
  → 抛 NoUniqueBeanDefinitionException:
    "expected single matching bean but found 2"

所以需要"消歧"机制：告诉 Spring 到底要哪个

问题的根源是「@Autowired 默认 byType，一个类型有多个 Bean 就无法确定」——抛 NoUniqueBeanDefinitionException。这在「一个接口多个实现」时很常见（各种支付、各种存储）。需要「消歧」机制告诉 Spring 选哪个。理解「@Autowired 默认 byType、多个同类型 Bean 导致歧义报 NoUniqueBeanDefinitionException、需要消歧机制」，就理解了这几个手段要解决的问题。

二、@Primary：设一个默认首选

@Primary 是最简单的消歧——「指定一个默认」：

在某个实现类上标 @Primary：
  @Service @Primary
  public class AliPayService implements PayService { }

含义：当有多个候选、且注入点没明确指定时，优先用这个
  @Autowired PayService payService;  → 注入 AliPayService

规则：
  - 一个类型只能有一个 @Primary（多个又会歧义）
  - 它是"兜底默认"——没有更明确指定（@Qualifier）时才用它
  - 优先级低于 @Qualifier

适用：一个接口有多个实现，但有个"主力实现"（90% 场景用它）
  → 标 @Primary，大部分注入点不用写 @Qualifier，省事

@Primary 是「设一个默认首选」——标在某个实现类上，没有更明确指定时就用它（一个类型只能有一个）。它是「兜底默认」，优先级低于 @Qualifier。适用于「有个主力实现，大部分场景都用它」，这样多数注入点不用写 @Qualifier。理解「@Primary 设默认首选、一个类型只能一个、是兜底默认、优先级低于 @Qualifier、适合有主力实现的场景」，就掌握了 @Primary。

三、@Qualifier：精确指定某一个

@Qualifier 是「精确指定」——在注入点明确说要哪个：

在注入点用 @Qualifier 指定 Bean 名/限定符：
  @Autowired @Qualifier("wechatPayService")
  private PayService pay;
  → 明确注入名为 wechatPayService 的 Bean

规则：
  - 用在注入点（字段/参数），不是实现类上
  - 优先级最高：即使有 @Primary，@Qualifier 也覆盖它
  - 参数值默认是 Bean 名，也可以是自定义限定符

自定义限定符（更语义化）：
  定义 @Qualifier 派生注解，如 @WechatPay
  在实现类上标 @WechatPay，注入点也用 @WechatPay
  → 比字符串 Bean 名更类型安全、更语义化

适用：明确知道这个注入点要用哪个特定实现

@Qualifier 是「精确指定要哪个 Bean」——用在注入点，参数是 Bean 名或自定义限定符。它优先级最高（覆盖 @Primary）。还能定义自定义限定符注解（如 @WechatPay）比字符串 Bean 名更语义化、类型安全。适用于「明确知道这个注入点要哪个特定实现」。理解「@Qualifier 精确指定 Bean(用在注入点)、优先级最高覆盖 @Primary、可自定义限定符注解更语义化」，就掌握了 @Qualifier。

四、byType 失败后的退化：字段名匹配

@Autowired 有个「隐式的消歧兜底」——用字段名当 Bean 名匹配：

@Autowired 的完整匹配逻辑：
  1. 先 byType 找候选
  2. 只有一个 → 注入
  3. 多个候选 → 尝试用"字段名/参数名"当 Bean 名去匹配
     @Autowired PayService aliPayService;
     → 有多个 PayService，但字段名 aliPayService
       正好匹配一个 Bean 名 → 注入它
  4. 还是定不下来（有 @Primary 用它，有 @Qualifier 用它）
  5. 都不行 → 抛 NoUniqueBeanDefinitionException

所以：字段名/参数名"碰巧"等于某个 Bean 名，也能消歧
  → 但这种"隐式匹配"可读性差、易踩坑（改字段名就注入变了）
  → 不如显式用 @Qualifier

@Autowired 在 byType 不唯一时，会退化用字段名/参数名当 Bean 名匹配——字段名正好等于某个 Bean 名就注入它。这是隐式的兜底消歧。但这种「靠字段名」的方式可读性差、易踩坑（改个字段名注入的 Bean 就变了），不如显式 @Qualifier。理解「@Autowired byType 不唯一时退化用字段名当 Bean 名匹配、是隐式消歧、但可读性差应显式用 @Qualifier」，就理解了这个容易忽视的匹配规则。

五、集合注入：一次拿到所有实现

如果目的不是「选一个」而是「要全部」，用集合注入：

注入所有实现：
  @Autowired List<PayService> list;         // 所有 PayService 实现（有序）
  @Autowired Map<String, PayService> map;   // key=Bean名, value=实现

List 的顺序：
  可用 @Order 或实现 Ordered 接口控制注入顺序
  （如责任链、过滤器链需要顺序）

Map 的 key：
  默认是 Bean 名（aliPayService → AliPayService 实例）

典型用途：
  ① 策略模式：收集所有策略，按需分发（下一节详解）
  ② 责任链：收集所有处理器，按 @Order 顺序依次处理
  ③ 插件式扩展：收集所有插件统一调用

集合注入是「一次拿到所有实现」——List<T>（所有实现，可用 @Order 排序）、Map<String,T>（key 是 Bean 名）。它把「一族实现」统一收集起来。典型用途：策略模式（收集所有策略）、责任链（按顺序处理）、插件扩展。这是「选一个」之外的另一种需求。理解「集合注入 List(所有实现可@Order排序)/Map<String,T>(key=Bean名)、一次拿到所有实现、用于策略/责任链/插件」，就掌握了集合注入。

六、集合注入 + 策略模式：消除 if-else

集合注入最有价值的应用是「策略模式消除 if-else」，值得单独讲透：

场景：根据支付类型，用不同的支付实现

❌ 传统 if-else（每加一种支付要改这里，违反开闭原则）：
  if (type.equals("ali")) return aliPay.pay();
  else if (type.equals("wechat")) return wechatPay.pay();
  else if (type.equals("union")) ...   // 越来越长

✅ 集合注入 + 查表分发：
  interface PayService {
      String getType();   // 每个实现自报"我处理什么类型"
      void pay();
  }
  // 注入所有实现，构建"类型→实现"的 Map
  @Autowired List<PayService> services;
  Map<String, PayService> strategyMap;
  @PostConstruct void init() {
      strategyMap = services.stream()
          .collect(toMap(PayService::getType, s -> s));
  }
  // 分发：查表，一行搞定
  public void pay(String type) {
      strategyMap.get(type).pay();
  }

★ 加一种新支付：只需加一个 @Service 实现类，分发逻辑一行不改！
  → 开闭原则（对扩展开放、对修改关闭）

策略模式是集合注入的杀手级应用——用「查表分发」代替「if-else 链」：让每个实现自报「我处理什么类型」，注入所有实现构建成「类型 → 实现」的 Map，分发时查表即可。加新实现只需加一个 @Component 类，分发逻辑一行不改（开闭原则）。这是 Spring 里消除 if-else、做可扩展策略的经典套路（各种支付、消息处理、导出格式都适用）。理解「集合注入构建’类型→实现’Map 查表分发替代 if-else、加新实现只加类不改分发逻辑、符合开闭原则、是策略模式经典套路」，就掌握了集合注入的最高价值。

记忆钩子：「一个接口多实现，@Autowired byType 歧义报 NoUniqueBeanDefinitionException；消歧手段：① @Primary(实现类上,设默认首选,一个类型只能一个,兜底默认) ② @Qualifier(注入点,精确指定 Bean,优先级最高覆盖 @Primary,可自定义限定符) ③ 字段名匹配(byType 不唯一时退化用字段名当 Bean 名,可读性差) ④ 集合注入 List(所有实现可@Order)/Map<String,T>(key=Bean名)；优先级 @Qualifier>@Primary>字段名；集合注入+策略模式:构建’类型→实现’Map 查表分发替代 if-else,加实现不改分发逻辑(开闭原则)」。

七、常见误区与追问

误区：一个接口有多个实现，@Autowired 会随便选一个。 不会——默认 byType，多个候选时抛 NoUniqueBeanDefinitionException（除非有 @Primary、@Qualifier 或字段名匹配上某个 Bean）；不消歧就启动失败。
误区：@Primary 和 @Qualifier 同时存在时用 @Primary。 @Qualifier 优先级更高——它是「精确指定」，会覆盖 @Primary（默认首选）；@Primary 只在注入点没有 @Qualifier 明确指定时才生效。
误区：@Primary 可以标在多个实现上。 一个类型只能有一个 @Primary——标多个又会歧义（有多个首选还是不知道选哪个），照样抛异常。
误区：集合注入拿不到所有实现。 恰恰能——@Autowired List 注入所有 T 类型的 Bean、Map<String,T> 注入所有（key 是 Bean 名）；这正是策略模式/责任链收集所有实现的方式。
追问：注入 List 的顺序能控制吗？ 能——在实现类上用 @Order(数字小的靠前) 或实现 Ordered 接口，注入的 List 会按此顺序排列；责任链、过滤器链等需要顺序的场景靠它保证执行次序。
追问：怎么用 Spring 优雅地消除策略分发的 if-else？ 让每个策略实现自报处理类型（getType），注入 List 或 Map<String,Strategy>，构建「类型→策略」的 Map，分发时 map.get(type).handle() 查表调用；加新策略只需加一个 @Component 实现，分发代码不用改——符合开闭原则。
追问：@Resource 和 @Autowired 在多实现时的默认行为有何不同？ @Autowired 默认 byType（不唯一时才退化按名字）；@Resource 默认 byName（先按名字找，找不到再 byType）——所以 @Resource(name=“x”) 或字段名就是主要的选择依据，行为上比 @Autowired 更依赖名字。

八、加强记忆

一个接口有多个实现时，@Autowired（默认 byType）会因多个候选而歧义，抛 NoUniqueBeanDefinitionException。消歧手段：① @Primary——标在实现类上设为「默认首选」（一个类型只能一个，是兜底默认，优先级低），适合有主力实现的场景；② @Qualifier("beanName")——用在注入点精确指定要哪个 Bean（优先级最高，覆盖 @Primary，可定义自定义限定符注解如 @WechatPay 更语义化）；③ 字段名匹配——@Autowired byType 不唯一时退化用字段名/参数名当 Bean 名匹配（隐式、可读性差，不如显式 @Qualifier）；④ 集合注入——List<T>（所有实现，@Order/Ordered 控制顺序）、Map<String,T>（key 是 Bean 名），一次拿到所有实现。优先级：@Qualifier > @Primary > 字段名匹配。集合注入的杀手级应用是策略模式消除 if-else：让每个实现自报处理类型，注入所有实现构建「类型→实现」的 Map，查表分发替代 if-else 链，加新实现只需加 @Component 类、分发逻辑一行不改（开闭原则）。一句话「多实现注入歧义：@Primary 设默认首选(实现类上,兜底)/@Qualifier 精确指定(注入点,优先级最高)/字段名退化匹配/集合注入 List·Map 拿全部；优先级 @Qualifier>@Primary>字段名；集合注入+策略模式构建’类型→实现’Map 查表分发,加实现不改代码符合开闭原则」。

简化版

详细版