@Autowired 和 @Resource 注解的区别是什么？-java教程-PHP中文网

@Autowired按类型注入，需@Qualifier或@Primary解决多实例歧义；@Resource优先按名称注入，名称不匹配时按类型，更利于名称明确的场景。

@autowired 和 @resource 注解的区别是什么？

@Autowired 侧重于按类型进行依赖注入，是 Spring 框架特有的；而 @Resource 则优先按名称进行注入，是 Java EE 规范的一部分，可以脱离 Spring 独立使用。

解决方案

理解

@Autowired

登录后复制

和

@Resource

登录后复制

的区别，说到底就是理解它们在查找和匹配依赖时的策略差异。

@Autowired：Spring 的类型优先策略

@Autowired

登录后复制

是 Spring 框架提供的注解，它的核心思想是“按类型装配”（by type）。当你在一个字段、构造器或 Setter 方法上使用

@Autowired

登录后复制

时，Spring 容器会尝试在它管理的 Bean 中找到一个类型匹配的 Bean 来进行注入。

例如：

@Component
public class MyService {
    @Autowired
    private MyRepository myRepository; // Spring会寻找MyRepository类型的Bean
    // ...
}

登录后复制

这里，Spring 会在容器中查找

MyRepository

登录后复制

接口或类的实现。如果容器中只有一个

MyRepository

登录后复制

类型的 Bean，那么它就会被成功注入。但如果容器中有多个

MyRepository

登录后复制

类型的 Bean（比如

MyRepositoryImplA

登录后复制

和

MyRepositoryImplB

登录后复制

都实现了

MyRepository

登录后复制

接口），Spring 就会感到困惑，抛出

NoUniqueBeanDefinitionException

登录后复制

异常，因为它不知道该注入哪一个。

为了解决这种歧义，你可以配合

@Qualifier

登录后复制

注解，明确指定要注入的 Bean 的名称：

@Component
public class MyService {
    @Autowired
    @Qualifier("myRepositoryImplA") // 明确指定Bean的名称
    private MyRepository myRepository;
    // ...
}

登录后复制

或者，你也可以将其中一个实现类标记为

@Primary

登录后复制

，告诉 Spring 在有多个相同类型的 Bean 时，优先选择这个：

@Component
@Primary
public class MyRepositoryImplA implements MyRepository { /* ... */ }

@Component
public class MyRepositoryImplB implements MyRepository { /* ... */ }

// MyService中无需@Qualifier，Spring会默认注入MyRepositoryImplA
@Component
public class MyService {
    @Autowired
    private MyRepository myRepository;
    // ...
}

登录后复制

@Resource：Java EE 的名称优先策略

@Resource

登录后复制

注解是 JSR-250 规范的一部分，这意味着它不局限于 Spring 框架，也可以在其他 Java EE 容器（如 Tomcat、Glassfish）中使用。它的默认行为是“按名称装配”（by name）。

当你在一个字段或 Setter 方法上使用

@Resource

登录后复制

时，它的查找顺序是这样的：

按名称查找： 默认情况下，
```
@Resource
```
登录后复制
会尝试将注解所在字段的名称（或者 Setter 方法对应的属性名）作为 Bean 的名称去容器中查找。
```
@Component
public class MyService {
    @Resource
    private MyRepository myRepositoryImplA; // 会尝试查找名为"myRepositoryImplA"的Bean
    // ...
}
```
登录后复制
如果找到了，就注入。
按类型查找： 如果按名称没有找到匹配的 Bean，
```
@Resource
```
登录后复制
就会退而求其次，尝试按类型进行查找。如果找到一个类型匹配的 Bean，就注入。如果找到多个类型匹配的 Bean，它会抛出异常。

你也可以通过

@Resource

登录后复制

的

name

登录后复制

属性明确指定要注入的 Bean 的名称：

@Component
public class MyService {
    @Resource(name = "myRepositoryImplA") // 明确指定Bean的名称
    private MyRepository myRepository;
    // ...
}

登录后复制

或者通过

type

登录后复制

属性指定类型，但这通常不如

name

登录后复制

属性常用，因为名称匹配是其核心优势：

@Component
public class MyService {
    @Resource(type = MyRepository.class) // 按类型查找
    private MyRepository someRepository;
    // ...
}

登录后复制

总结来说，核心差异是：

@Autowired

登录后复制

默认是类型优先，需要

Qualifier

登录后复制

辅助名称；

@Resource

登录后复制

默认是名称优先，找不到名称再退化到类型。

Spring Boot开发中，何时优先选择@Autowired，何时选择@Resource？

在 Spring Boot 的日常开发中，选择

@Autowired

登录后复制

还是

@Resource

登录后复制

，这其实更多是一种个人习惯和团队规范的体现，当然，也有些场景会让我倾向于某一个。

我个人在多数情况下会更倾向于使用

@Autowired

登录后复制

。为什么呢？因为 Spring Boot 项目本身就是深度依赖 Spring 框架的，

@Autowired

登录后复制

作为 Spring 原生的注解，用起来感觉更“顺滑”，也更符合 Spring 的设计哲学——即通过类型来建立依赖关系。当我在一个纯粹的 Spring 环境中工作时，我希望我的代码能够充分利用 Spring 提供的便利，而

@Autowired

登录后复制

恰好提供了这种简洁和直观的类型匹配能力。特别是当我的接口只有一个实现类时，

@Autowired

登录后复制

几乎是零配置，非常方便。如果遇到多实现的情况，

@Qualifier

登录后复制

的存在也提供了一个优雅的解决方案。

然而，在某些特定的场景下，我会发现

@Resource

登录后复制

更有用武之地。比如，当我在处理一些遗留系统，或者与一些第三方库集成时，这些库可能在 Spring 容器中注册了一些名称很明确的 Bean，但它们的类型可能比较通用，或者我只是想通过一个特定的名称来引用它们。这时候，

@Resource

登录后复制

的名称优先匹配策略就显得非常直接和清晰，它能够减少潜在的类型匹配混淆。

再比如，如果我需要在代码中显式地通过一个字符串名称来引用一个 Bean（这在某些动态配置或工厂模式中可能会出现），那么

@Resource(name="beanName")

登录后复制

的表达力就比

@Autowired

登录后复制

结合

@Qualifier("beanName")

登录后复制

显得更直接一些，因为它把“按名称注入”这个意图放在了注解本身。

另外，从代码的可移植性角度看，

@Resource

登录后复制

因为是 Java EE 规范的一部分，理论上它的代码可以更容易地迁移到其他支持 JSR-250 的 Java EE 容器中。尽管在 Spring Boot 项目中，这种可移植性优势往往被淡化了（因为你已经选择了 Spring），但对于那些对规范性有较高要求，或者未来有潜在迁移需求的项目，

@Resource

登录后复制

确实提供了一种更标准化的选择。

魔乐社区

天翼云和华为联合打造的AI开发者社区，支持AI模型评测训练、全流程开发应用

102

查看详情

所以，我的经验是：对于大多数 Spring Boot 应用的内部组件依赖，

@Autowired

登录后复制

是一个非常好的默认选择；而当涉及到与外部系统集成、处理遗留代码、或者需要通过明确名称来消除歧义时，

@Resource

登录后复制

会是更稳健和清晰的选择。

如果存在多个相同类型的Bean，这两种注解会如何处理？

处理多个相同类型的 Bean，是我们在 Spring 开发中经常会遇到的一个挑战，也是区分

@Autowired

登录后复制

和

@Resource

登录后复制

行为的关键点。

@Autowired 的处理方式：

当 Spring 容器中存在多个类型相同的 Bean，而你又使用了

@Autowired

登录后复制

进行注入时，如果没有额外的指示，Spring 会感到“不知所措”，因为它不知道应该选择哪一个 Bean。在这种情况下，它会抛出一个

NoUniqueBeanDefinitionException

登录后复制

异常。这个异常会明确告诉你，容器中找到了多个符合类型的 Bean，需要你进行进一步的明确。

为了解决这个问题，通常有以下几种方法：

使用

@Qualifier

登录后复制

：这是最常用也最推荐的方式。通过在

@Autowired

登录后复制

的同时加上

@Qualifier("beanName")

登录后复制

，你可以明确告诉 Spring 要注入哪个具体名称的 Bean。

@Service("smsSender")
public class SmsSender implements MessageSender { /* ... */ }

@Service("emailSender")
public class EmailSender implements MessageSender { /* ... */ }

@Component
public class NotificationService {
    @Autowired
    @Qualifier("emailSender") // 明确指定注入名为 "emailSender" 的Bean
    private MessageSender messageSender;
}

登录后复制

使用

@Primary

登录后复制

：如果你希望在多个相同类型的 Bean 中，有一个是默认优先被注入的，你可以将该 Bean 标记为

@Primary

登录后复制

。这样，当 Spring 遇到类型冲突时，会优先选择带有

@Primary

登录后复制

注解的 Bean。

@Service
@Primary // 优先选择这个发送器
public class DefaultSmsSender implements MessageSender { /* ... */ }

@Service
public class BackupEmailSender implements MessageSender { /* ... */ }

@Component
public class NotificationService {
    @Autowired // 会自动注入 DefaultSmsSender
    private MessageSender messageSender;
}

登录后复制

通过参数名匹配（作为后备）： 如果没有
```
@Qualifier
```
登录后复制
也没有
```
@Primary
```
登录后复制
，Spring 还会尝试将要注入的字段名或参数名作为 Bean 的名称进行匹配。但这种方式不如前两种明确，且容易引发混淆，我个人不太推荐在多 Bean 场景下依赖它。

@Resource 的处理方式：

@Resource

登录后复制

在处理多个相同类型的 Bean 时，其行为逻辑有所不同，因为它本身就是名称优先的。

优先按名称查找： 当你使用

@Resource

登录后复制

注解时，它会首先尝试根据字段名（或 Setter 方法名）来查找 Bean。如果找到了一个名称匹配的 Bean，即使有多个相同类型的 Bean，它也会直接注入这个名称匹配的 Bean，不会引发歧义。

@Service("smsSender")
public class SmsSender implements MessageSender { /* ... */ }

@Service("emailSender")
public class EmailSender implements MessageSender { /* ... */ }

@Component
public class NotificationService {
    @Resource // 尝试查找名为 "smsSender" 的Bean
    private MessageSender smsSender;

    @Resource // 尝试查找名为 "emailSender" 的Bean
    private MessageSender emailSender;
}

登录后复制

如果按名称未找到，再按类型查找： 如果
```
@Resource
```
登录后复制
没有通过名称找到匹配的 Bean，它才会退而求其次，尝试按类型进行查找。在这种情况下，如果容器中存在多个相同类型的 Bean，并且它们都没有被
```
@Resource
```
登录后复制
的名称属性明确指定，那么
```
@Resource
```
登录后复制
同样会抛出异常，因为它无法决定注入哪一个。

所以，从处理多 Bean 的角度看，

@Resource

登录后复制

在一开始就通过名称匹配的策略，能够在很多情况下避免歧义。而

@Autowired

登录后复制

则需要你显式地通过

@Qualifier

登录后复制

或

@Primary

登录后复制

来解决这种歧义。

从代码可移植性和规范性角度，这两种注解有何优劣？

谈到代码的可移植性和规范性，

@Autowired

登录后复制

和

@Resource

登录后复制

确实展现出了不同的哲学和定位。

@Autowired：Spring 框架的深度整合与便捷性

优点：
- 与 Spring 深度整合：
```
@Autowired
```
  登录后复制
  是 Spring 框架的核心组成部分，它与 Spring 的 IoC 容器、AOP、事务管理等功能无缝集成。在纯 Spring 或 Spring Boot 项目中，使用
```
@Autowired
```
  登录后复制
  感觉非常自然，也最能体现 Spring 的“约定优于配置”理念。
- 简洁性： 对于大多数只有单一实现类的接口，
```
@Autowired
```
  登录后复制
  几乎是零配置，代码非常简洁。
- 类型安全： 默认的类型匹配策略在编译时就能发现一些潜在的类型不匹配问题（当然，运行时找不到 Bean 还是会报错）。
缺点：
- 框架耦合度高： 这是最主要的“劣势”。
```
@Autowired
```
  登录后复制
  是 Spring 特有的注解，如果你的代码将来需要从 Spring 容器迁移到其他非 Spring 的 IoC 容器（比如一个纯 Java EE 容器，或者一个自定义的轻量级容器），那么所有使用了
```
@Autowired
```
  登录后复制
  的地方都需要进行修改。这会增加迁移成本。当然，在实际的 Spring Boot 项目中，这种迁移的可能性通常很低，因为 Spring Boot 本身就意味着对 Spring 生态的深度依赖。
- 默认行为可能引发歧义： 如前所述，在存在多个相同类型的 Bean 时，
```
@Autowired
```
  登录后复制
  默认会报错，需要额外的
```
@Qualifier
```
  登录后复制
  或
```
@Primary
```
  登录后复制
  来解决。

@Resource：Java EE 标准的通用性与规范性

优点：
- 高可移植性： 这是
```
@Resource
```
  登录后复制
  最显著的优势。作为 JSR-250 规范的一部分，
```
@Resource
```
  登录后复制
  是 Java EE 容器的标准注解。这意味着使用了
```
@Resource
```
  登录后复制
  的代码理论上可以在任何支持 JSR-250 的 Java EE 容器中工作，而不仅仅局限于 Spring。对于那些需要考虑跨平台或未来可能迁移到不同容器的场景，
```
@Resource
```
  登录后复制
  提供了一层抽象，降低了框架锁定的风险。
- 规范性： 遵循 Java EE 规范，使得代码在宏观上更具“标准”感，这对于一些对架构规范有严格要求的企业或项目来说可能是一个加分项。
- 名称优先的清晰性： 其默认的名称匹配策略在很多情况下能够更直观地表达注入意图，尤其是在 Bean 名称具有明确业务含义时。
缺点：
- 与 Spring 框架的集成不如
  @Autowired
  登录后复制
  紧密：尽管 Spring 完全支持
```
@Resource
```
  登录后复制
  ，但它毕竟不是 Spring 原生的。在某些 Spring 特有的高级特性或扩展点上，
```
@Autowired
```
  登录后复制
  可能表现得更自然。
- 在 Spring Boot 环境下，可移植性优势可能被弱化： 就像我前面说的，一旦你选择了 Spring Boot，你通常就已经接受了对 Spring 框架的深度依赖。在这种情况下，
```
@Resource
```
  登录后复制
  的可移植性优势在实践中可能并不那么突出。