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

一、先厘清背景：依赖注入与两个注解的“出身”

在现代Java企业级开发中，IoC容器负责对象的创建、组装与生命周期管理。开发者不再手动new依赖对象，只需声明“我需要什么”，容器就会把合适的实例注入进来，这就是依赖注入（Dependency Injection，DI）。@Autowired与@Resource正是完成这件事时最常用的两个注解，但它们并非“同门”：

• @Autowired 由主流依赖注入框架自身提供，是容器装配体系的“原生注解”，行为与容器的装配流程深度绑定；
• @Resource 由Java标准规范定义，属于公共注解，不绑定任何特定容器实现，理论上任何遵循该规范的容器都应支持它。

出身不同，直接决定了两者在默认装配策略、多候选收敛方式、容错机制上的系统性差异。下面逐一展开。

二、@Autowired：默认按类型装配

先看最常见的用法：

@Service
public class OrderService {
    public void createOrder() { }
}
@Service
public class PayService {
    @Autowired
    private OrderService orderService;
}

容器启动后，PayService中的orderService会被自动赋值。默认情况下，@Autowired按类型装配，也就是常说的byType：容器在所有受管Bean中筛选与目标类型匹配的实例，只要候选唯一，注入即可成功。

再看required参数。它的默认值是true，表示该依赖“必须装配成功”：一旦找不到候选对象，容器会在启动阶段直接失败。这种“快速失败”的设计很有价值——问题在部署时暴露，而不是运行到一半才抛出空指针异常。如果某个依赖确实可有可无，可以将required设为false，此时找不到候选对象不会报错，字段保持null，由业务代码自行判空。

需要提醒的是，required=false应当谨慎使用。它把“依赖是否存在”的判断责任转移给了业务代码，一旦遗漏判空，隐患会延后爆发。绝大多数业务依赖都是必需的，保持默认值通常是更稳妥的选择。

三、@Resource：默认按名称装配

@Resource的装配逻辑与@Autowired有本质区别，其匹配顺序可概括为三步：

1. 若显式指定了name属性，则严格按该名称查找Bean，找不到直接报错，不会回退；
2. 若未指定name，默认取字段名作为Bean名称去匹配（用于setter注入时，取去掉set前缀后的属性名）；
3. 按名称未命中时，回退为按类型装配；若该类型存在多个候选，同样会陷入歧义。

@Service("orderServiceMain")
public class OrderService { ... }
@Service
public class PayService {
    @Resource
    private OrderService orderServiceMain; // 字段名与Bean名称一致，精准命中
    @Resource(name = "orderServiceMain")
    private OrderService orderService;     // 显式指定名称，效果等价
}

这种“名称优先”的策略，让@Resource在多实现场景下可以直接靠命名定位目标Bean，无需引入额外注解。

四、同类型多个Bean时：两者行为差异的全景对比

byType成立的前提是“该类型的候选Bean唯一”。当同一类型存在多个实例时——例如一个接口有两个实现类——注入就会产生歧义。此时两个注解的应对方式截然不同。

@Autowired的收敛顺序：

1. 先按类型筛出全部候选；
2. 候选多于一个时，优先选择标注了@Primary的Bean（即“默认首选者”）；
3. 其次看是否通过@Qualifier显式指定了名称；
4. 再尝试用字段名（或构造器参数名）与Bean名称匹配；
5. 仍无法唯一确定，容器抛出“候选对象不唯一”的异常，启动失败。

public interface MessageSender {
    void send(String message);
}
@Service
public class EmailSender implements MessageSender { ... }
@Primary
@Service
public class SmsSender implements MessageSender { ... }

上述代码中，@Autowired注入MessageSender时，SmsSender因标注@Primary而胜出；若想注入EmailSender，可用@Qualifier(“emailSender”)精确指定，或改用@Resource并把字段名写成emailSender。注意，@Primary与@Qualifier是同一装配体系提供的配套注解，与@Autowired配合使用最为自然。

五、一个高频误区：Bean名称冲突 ≠ 注入歧义

很多同学在验证“同类型多对象”时，会走这样一条路：在测试目录下新建一个与线上服务类同名的类，同样加@Service注解。结果项目根本起不来，直接抛出“Bean定义冲突”异常：

package com.demo.service;
@Service
public class TestService1 { ... }
// 测试目录下，不同包但同名
package com.demo.service.test;
@Service
public class TestService1 { ... }

启动报错的核心信息是：注解指定的Bean名称与已存在的、不兼容的Bean定义发生冲突。

根因剖析： 容器默认会把类名首字母小写，作为该Bean的名称，例如TestService1对应testService1。两个不同包下的同名类，会派生出完全相同的默认Bean名称，而Bean名称在整个容器中必须全局唯一，注册阶段校验不通过，应用直接启动失败。

这里必须澄清一个极易混淆的点：

• 该报错发生在Bean注册阶段，本质是“两个类抢同一个默认名字”；
• 它与注入阶段“同一类型存在多个候选”是两类完全不同的问题，后者发生在依赖装配阶段；
• 因此这个场景并不能用来验证byType的歧义行为；验证歧义，应当用“一个接口、多个实现”的方式来构造。

解决方案也很简单：给其中一个类显式指定Bean名称，错开默认名即可：

@Service("testService1ForTest")
public class TestService1 { ... }

六、选型建议与工程最佳实践

1. 注入方式比注解选择更重要。 业界普遍推荐：构造器注入 > setter注入 > 字段注入。构造器注入保证依赖不可变、便于单元测试、依赖关系显式可见，还能更早暴露循环依赖。@Autowired支持构造器、字段、setter等多种位置；@Resource只支持字段与setter方式，不支持构造器注入，这是两者能力面上的一个实际差异。
2. 单实现场景： 两者等价，任选其一并保持团队统一即可。
3. 多实现场景： 优先方案是用@Primary声明默认实现、@Qualifier精确指定；若偏好“名称即一切”的直观风格，统一使用@Resource(name = “…”)也完全可行。
4. 可移植性考量： 若代码未来可能脱离当前容器被复用（例如迁移到其他规范兼容的容器），@Resource作为标准注解耦合更低、更稳妥。
5. 留意标准注解的包名演进： 随着Java规范的演进，公共注解所在的包名可能发生调整（由旧前缀迁移到新命名空间），升级运行环境时注意同步修正import，避免编译期踩坑。
6. 守住Bean命名规范： 避免在不同包下定义同名类并交给容器管理；团队可约定类名携带业务前缀，从源头规避默认名称冲突。

七、总结

对比维度	@Autowired	@Resource
注解来源	依赖注入框架原生提供	Java标准规范定义的公共注解
默认装配策略	按类型	按名称，未命中回退按类型
指定目标Bean	配合@Qualifier	name属性
多候选收敛	@Primary > @Qualifier > 名称匹配	名称直接命中
缺失依赖处理	required=false可放宽	无可选语义，找不到即失败
支持注入位置	构造器、字段、setter、任意方法	字段、setter

一句话收束：@Autowired是“类型优先”的框架原生注解，@Resource是“名称优先”的标准注解。理解“注册阶段的命名冲突”与“注入阶段的候选歧义”这两类问题的边界，再结合构造器注入等最佳实践，就能在绝大多数场景下做出清晰、可维护的装配选择。