既然@Qualifier可指定依赖，为何还需要@Primary？

一、始终使用@Qualifier的问题 #

• 冗余重复：如果绝大多数场景都依赖同一个实现（比如示例里的FooFormatter），每次注入都写@Qualifier("FooFormatter")会产生大量重复代码，后续类名变更时，所有注入点都要同步修改，维护成本陡增。
• 心智负担：每个注入点都要明确指定Bean名称，开发时必须时刻牢记所有实现类的Bean标识，项目中同一接口实现越多，越容易因写错名称导致注入失败。
• 违背"约定大于配置"：Spring的核心设计理念之一是减少显式配置，过度使用@Qualifier会让配置变得繁琐，丧失框架简化开发的优势。

二、为什么需要@Primary？ #

@Primary的核心价值是提供默认依赖选择，和@Qualifier是互补关系，而非替代，主要解决"多数场景用默认实现，少数场景用特殊实现"的需求：

1. 简化多数场景的注入 #

拿你的示例来说，如果80%的注入场景都需要FooFormatter，给它标记@Primary后，这些场景直接写@Autowired就能自动注入默认实现，无需重复添加@Qualifier：

// 无需@Qualifier，自动注入被@Primary标记的FooFormatter
@Autowired
private Formatter defaultFormatter;

2. 兼容第三方库/自动配置 #

在Spring Boot自动配置场景中，很多第三方组件会提供默认Bean实现。比如Spring Data JPA的EntityManagerFactory，默认有一个自动配置的Bean，如果你自定义了另一个EntityManagerFactory，只需给你的Bean加@Primary，原有代码无需修改就能自动切换到你的实现，大幅降低大型项目的改造成本。

3. 语义化标记增强可读性 #

@Primary是一种清晰的语义化标记，能直接告诉其他开发者：这个Bean是该接口的默认首选实现，其他实现仅用于特殊场景。相比到处写@Qualifier，这种标记让代码的意图更明确，团队协作时减少沟通成本。

三、两者共存的实用场景 #

当需要在少数场景使用非默认实现时，用@Qualifier覆盖@Primary的默认选择即可，比如：

// 覆盖默认配置，注入BarFormatter
@Qualifier("barFormatter")
@Autowired
private Formatter specialFormatter;

这种组合既满足了多数场景的简洁性，又支持少数场景的灵活配置，是Spring依赖注入中非常实用的搭配。

内容的提问来源于stack exchange，提问作者Parshant