一文讲透@Autowired与@Resource的区别

在 Spring Boot 项目的日常开发中，@Autowired 和 @Resource 几乎是使用频率最高的两个依赖注入注解。很多人会把它们当成“可以互相替换”的同义词，随手挑一个就用。事实上，二者从出身到装配策略都存在本质区别，一旦遇到同类型多 Bean 的场景，这种区别会直接决定项目能否启动成功。本文结合代码示例，把两者的差异一次性讲透。

一、出身不同：框架私有注解 vs JSR 标准注解

第一个区别藏在 import 语句里。

@Autowired 由 Spring 框架自己定义，位于 org.springframework.beans.factory.annotation 包下，属于 Spring 生态的“私有”注解——只有 Spring 容器认识它，脱离 Spring 环境它就毫无意义。

@Resource 则来自 JSR-250 规范，早期位于 javax.annotation 包，Jakarta EE 9 之后迁移到了 jakarta.annotation 包。它是 Java 标准层面的注解，理论上任何支持该规范的容器都能识别，通用性和可移植性更强。

这个差异有一个非常现实的影响：升级到 Spring Boot 3.x 后，JDK 基线提升到 17，大量 javax. 包统一迁移为 jakarta.。如果代码里 @Resource 的 import 还停留在 javax.annotation.Resource，要么编译直接失败，要么注解静默失效、字段注入不生效，直到运行期才以空指针异常的形式暴露出来。这是升级过程中的高频坑，建议在团队规范中明确标注。

二、@Autowired 的默认装配策略：先按类型（byType）

先看一个最常规的用法：

package com.example.demo.service;
@Service
public class OrderService {
    public void create() {
        // 下单业务逻辑
    }
}

package com.example.demo.service;
@Service
public class TradeService {
    @Autowired
    private OrderService orderService;
    public void trade() {
        orderService.create();
    }
}

容器中 OrderService 类型的 Bean 只有一个，按类型就能唯一定位，注入顺利完成。这就是 byType 的含义。

再看 required 属性，它默认为 true，表示“这个依赖必须存在”。找不到匹配的 Bean 时，容器会在启动阶段直接抛出 NoSuchBeanDefinitionException，让问题尽早暴露。如果某个依赖确实是可选的，可以显式声明：

@Autowired(required = false)
private OrderService orderService;

此时容器中即便没有匹配的 Bean 也不会报错，字段会保持 null。但要清楚这是一个“定时炸弹”：启动阶段安静无事，业务真正调用到 orderService.create() 时才抛出 NullPointerException，问题被大幅延迟，排查成本随之上升。如果确实需要表达“可选依赖”，更推荐用 Optional 或 Spring 提供的 ObjectProvider，语义更清晰，也更类型安全。

三、同类型 Bean 不止一个时，会发生什么

byType 能顺利工作的前提是：该类型在容器中唯一。一旦出现多个候选，类型就无法唯一定位目标了。构造一个典型场景：

public interface MessageService {
    void send(String content);
}
@Service
public class EmailMessageService implements MessageService {
    @Override
    public void send(String content) {
        // 邮件发送逻辑
    }
}
@Service
public class SmsMessageService implements MessageService {
    @Override
    public void send(String content) {
        // 短信发送逻辑
    }
}

然后注入：

@Service
public class NotifyService {
    @Autowired
    private MessageService messageService; // 启动失败
}

此时启动会直接报错，典型的异常信息类似：

NoUniqueBeanDefinitionException:
Expected single matching bean but found 2: emailMessageService, smsMessageService

除了接口多实现，还有一种更隐蔽的情况：在测试源码目录下创建了与主代码同名的类。执行测试时，测试类路径同样会被组件扫描覆盖，主代码与测试代码中的同名类会一起注册进容器，于是“只在跑测试时启动失败”的诡异问题就出现了。如果两个类的默认 Bean 名称（类名首字母小写）也相同，还可能在扫描阶段就触发 Bean 定义冲突。遇到这类问题的排查思路就是：先确认容器中到底注册了哪些同类型的 Bean。

面对多个候选，@Autowired 有三种消歧手段：

1. @Primary：在某个实现类上标注 @Primary，声明它是“默认首选”，存在多个候选时优先选中它；
2. @Qualifier：在注入点通过 @Qualifier(“smsMessageService”) 精确指定目标 Bean，把选择权明确写进代码；
3. 字段名兜底：当上述手段都没使用时，Spring 会尝试用被注入字段名与候选 Bean 的名称做匹配，匹配上就选它。

需要特别提醒的是第三种：它是 Spring 的隐式兜底行为，虽然“字段名恰好等于 Bean 名”时确实能装配成功，但一旦后续有人重命名字段，装配结果就可能悄然改变，甚至直接启动失败。依赖这种隐式规则等于埋雷，生产代码里应该显式声明目标。

四、@Resource 的默认装配策略：先按名称（byName）

@Resource 的解析由 CommonAnnotationBeanPostProcessor 完成，与 @Autowired 的处理器 AutowiredAnnotationBeanPostProcessor 完全不同，这正是两者行为差异的根源。它的装配流程可以概括为三步：

1. 如果显式指定了 name，就只按名称查找，找到即注入；找不到直接报错，不会退回按类型匹配；
2. 如果没有指定 name，会把字段名（或 setter 对应的属性名）作为默认名称，先按这个名称查找；
3. 如果默认名称也找不到对应的 Bean，则退化为按类型（byType）匹配。

对应到上面的多实现场景：

@Service
public class NotifyService {
    @Resource
    private MessageService smsMessageService;
}

字段名 smsMessageService 恰好等于某个候选 Bean 的名称，第一步按名称匹配就命中了，注入成功。这也是很多人觉得“@Resource 在多 Bean 场景下更好用”的原因——其实是字段名隐式完成了名称匹配。

当然也可以显式指定，语义更清晰：

@Resource(name = "smsMessageService")
private MessageService messageService;

但要注意，@Resource 并不是多实现场景的“万能解”。如果字段名与任何候选 Bean 的名称都不一致，它会退回按类型匹配，此时面对多个候选同样会抛出 NoUniqueBeanDefinitionException。所以无论用哪个注解，多实现场景下显式指定目标，才是最稳妥的做法。

五、其他几个容易被忽略的差异

除了装配策略，两者还有几处细节差异，实战和面试中都经常被问到：

1. 可标注位置不同。@Autowired 可以标注在构造器、字段、setter 方法、任意多参数的普通方法上，甚至可以标注在参数上；@Resource 只能标注在字段和 setter 方法上，不支持构造器。这一点直接决定了：如果团队采用官方推荐的构造器注入，@Resource 根本没有出场机会。顺带一提，从 Spring 4.3 开始，一个类如果只有一个构造器，构造器上的 @Autowired 可以省略，代码更加简洁。

2. 属性能力不同。@Autowired 提供的是 required 属性，控制“依赖是否必须”；@Resource 提供的是 name 和 type 属性，控制“按什么找、找到后是否校验类型”。从属性设计上就能看出两者侧重点完全不同：一个关心“要不要注入”，一个关心“怎么找”。

3. 与其他注解的配合不同。@Autowired 通常配合 @Qualifier、@Primary 完成精细控制；@Resource 自身就带 name 属性，一般不与 @Qualifier 搭配使用。

六、一张表总结核心差异

对比维度	@Autowired	@Resource
注解来源	Spring 框架私有注解	JSR-250 标准注解（javax/jakarta）
默认装配策略	先按类型（byType）	先按名称（byName），找不到再按类型
多候选处理	@Primary → 字段名匹配 → 报错	显式指定 name 即可精确命中
核心属性	required	name、type
可标注位置	构造器、字段、setter、普通方法、参数	字段、setter 方法
依赖不存在时	required=false 可跳过注入	直接报错（无“可选”开关）

七、实践建议

结合两者差异，给出几条可直接落地的建议：

1. 优先采用构造器注入。字段可以声明为 final，对象不可变、线程安全性更好；依赖关系全部显式出现在构造器签名中，单元测试可以直接构造对象，阅读代码时也能一眼看清依赖；装配问题在启动阶段就暴露，而不是拖到运行期。
2. 多实现场景必须显式消歧。不要依赖“字段名兜底”这类隐式行为，用 @Qualifier 配合 @Autowired，或用 @Resource 的 name 属性，明确写出目标 Bean，后续重构才不会踩坑。
3. 团队内统一选择。同一个项目里混用两种注解，会让代码呈现两种不同的装配语义，增加理解和排查成本。建议在编码规范中明确统一用哪一个，或约定清楚各自的使用场景，并保持一致性。
4. 谨慎使用 required=false。可选依赖优先考虑 Optional 或 ObjectProvider，让“可选”语义显式化，而不是留下一堆可能为 null 的字段。
5. 升级 Spring Boot 3 时，检查 @Resource 的 import 是否已切换到 jakarta 包，避免注解静默失效。

结语

@Autowired 与 @Resource 的区别，本质上不是“哪个更好用”，而是两套装配语义的选择：一个以类型为中心，一个以名称为中心。理解了这一点，再回头看“多 Bean 冲突为什么会报错”“为什么换个字段名就能注入成功”这类问题，答案就都顺理成章了。具体选哪个注解并不重要，重要的是团队统一、语义显式，让依赖注入这件事始终处于可控状态。