Spring Bean 注入
- 分两种情况，有@Qualifier和没有@Qualifier
- 如果有，则按Bean Name优先级最高去注入
- 如果没有，就按泛型 ->
name -> fallback name的顺序注入
大致理解：海选赛，最后必须有一个冠军
总结：自己新加的Bean 使用 @Qualifier
- 声明Bean和注入Bean对泛型的声明要保持一致，避免注入的时候有更详细的Bean信息，因为 Spring Bean 注入优先级的机制，匹配到了其他人的更详细定义的Bean
- 声明Bean的时候@Bean要尽量把bean name写出来
- 主要是针对一种极端情况，就是刚好新加了一个泛型，注入按照泛型去找，然后刚好找到了这个Bean
优先级最高法则：在 Spring 的自动装配中，显式指定的 @Qualifier 拥有绝对的优先权，它比泛型匹配、比 @Primary 的优先级都要高！
当 Spring 遇到一个 @Autowired 注入点时，它不是按部就班地走阶梯，而是像漏斗一样层层过滤。
阶段一：海选（按裸类型全盘捞出）
Spring 首先完全忽略泛型和 @Qualifier，只看裸类型（TigerMessageProducer），把容器里所有符合裸类型的 Bean 全部捞出来。 此时，候选名单里可能有很多个 Bean（包含 A 和 B）。
阶段二：半决赛（双重过滤：Qualifier 为主，泛型为辅）
这是最关键的一步！Spring 会在这一步同时应用 显式限定符（@Qualifier） 和 泛型类型推断，把不匹配的淘汰掉。
Spring 的淘汰逻辑是这样的：
如果注入点有 @Qualifier（指名道姓）：
Spring 直接在候选名单里找名字/标签匹配的 Bean。
一旦找到，Spring 会直接信任你，不再进行严苛的泛型校验（这就是为什么上一问中，泛型写错了也能注入成功的原因）。
如果没找到，直接报错（不会往下走了）。
如果注入点没有 @Qualifier（盲婚哑嫁）：
Spring 必须依靠泛型来筛选。
它会检查候选名单，把泛型不匹配的淘汰掉（比如把没有泛型的 A 淘汰，留下泛型匹配的 B）。
经过阶段二的过滤，剩下的才是"准候选者"。
阶段三：决赛（唯一性决断 + Fallback）
经过阶段二的过滤，看剩下几个人：
只剩 1 个：完美，直接注入，结束。
剩 0 个：报错 NoSuchBeanDefinitionException（除非 required=false）。
剩多个（还是冲突）：这时代码肯定没加 @Qualifier，泛型也无法区分了。Spring 只能祭出最后的 Fallback 机制，比对注入点的字段名（或参数名），看看能不能和剩下的某个候选 Bean 名字对上。对上了就注入，对不上直接报错 NoUniqueBeanDefinitionException。
@Qualifier 是"特权通道"：一旦使用，Spring 只看名字，无视泛型冲突（甚至允许泛型错配），直接保送。
泛型是"常规筛子"：在没有 @Qualifier 时，Spring 依靠泛型在多个候选者中精确筛选。
Fallback 是"最后挣扎"：只有当既没有 @Qualifier，泛型也无法区分出唯一者时，Spring 才会去猜字段名。