Spring Boot 依赖注入：@Autowired 与 @Resource 的差异与选型

在 Spring Boot 项目中，依赖注入几乎是每天都要写的代码。很多开发者习惯性地在字段上敲下 @Autowired，也有人偏爱 @Resource，两者都能让容器把 Bean 塞进目标对象，看起来“效果一样”。但一旦项目里出现同一类型的多个实现、代理对象、延迟初始化，或者需要按名称精确指定依赖时，两者的行为差异就会立刻暴露。本文从装配机制出发，把这两个注解拆开讲清楚，并给出实际的选型与排查建议。

一、先厘清概念：它们解决的是同一个问题

@Autowired 与 @Resource 的目标一致：完成依赖注入（Dependency Injection），把容器中已注册的 Bean 装配到当前对象的字段、构造器或方法参数上。区别不在“能不能注入”，而在“按什么规则找 Bean”“找不到时怎么办”“由谁来解析”。

理解这一点很重要，因为很多“注入失败”或“注入错了对象”的问题，本质上都是装配策略与解析顺序不一致导致的。

二、@Autowired：以类型为核心的装配

1. 默认按类型装配（byType）

@Autowired 由 Spring 框架自身提供，默认策略是按类型匹配。容器会在自己的 Bean 定义中查找与目标类型兼容的候选者，找到唯一匹配就完成注入。

@Service
public class OrderService {
    public void create() { }
}
@Service
public class TradeService {
    @Autowired
    private OrderService orderService; // 按类型找到唯一的 OrderService
    public void submit() {
        orderService.create();
    }
}

只要 OrderService 在容器中只有一个实例，这段代码就能稳定工作。这也是原文所强调的“默认 byType 方式”。

2. required 开关：控制“找不到就报错”还是“允许为空”

@Autowired 有一个 required 属性，默认值为 true，含义是：必须找到匹配的 Bean，否则启动阶段直接抛出异常。这在多数场景是好事——依赖缺失应当尽早暴露，而不是等到运行时才空指针。

当某些依赖确实可能不存在（例如按环境可选加载的组件）时，可以显式关闭：

@Service
public class ReportService {
    @Autowired(required = false)
    private AuditService auditService; // 容器中没有该 Bean 时为 null
    public void generate() {
        if (auditService != null) {
            auditService.record();
        }
    }
}

需要提醒的是：把 required 设为 false 相当于把“编译期/启动期的确定性”换成了“运行期的判空负担”。若非确有必要，更推荐通过配置类条件装配（如按 Profile、按条件注解决定是否注册 Bean）来管理可选依赖，让对象图在启动时就保持确定。

3. 类型冲突时的处理：名称兜底与限定符

当同一类型存在多个候选 Bean 时，按类型匹配不再唯一，Spring 会退化为按字段名/参数名与 Bean 名称匹配；若仍无法唯一确定，则抛出 NoUniqueBeanDefinitionException。此时更规范的解法是使用限定符明确指定：

public interface PayChannel { void pay(); }
@Service("alipayChannel")
public class AlipayChannel implements PayChannel { public void pay() { } }
@Service("wechatChannel")
public class WechatChannel implements PayChannel { public void pay() { } }
@Service
public class PayService {
    @Autowired
    @Qualifier("alipayChannel")
    private PayChannel payChannel;
}

相比依赖“字段名恰好等于 Bean 名”这种隐式约定，@Qualifier 显式表达了意图，重构时也更安全。

4. 可注入的位置不止字段

@Autowired 可标注在构造器、setter 方法、普通方法和字段上。构造器注入尤其值得推荐：依赖在对象创建时即完成装配，字段可声明为 final，天然规避循环依赖与空值问题，也便于单元测试直接 new 出对象。

@Service
public class InventoryService {
    private final StockRepository stockRepository;
    public InventoryService(StockRepository stockRepository) {
        this.stockRepository = stockRepository;
    }
}

另外，@Autowired 还可以注入集合类型，容器会把所有匹配类型的 Bean 收集进来，这在策略模式、插件式扩展中非常实用：

@Autowired
private List<PayChannel> channels; // 所有 PayChannel 实现

三、@Resource：以名称为先的解析策略

1. 来源不同，解析器不同

@Resource 来自 Java 标准（jakarta.annotation.Resource，旧版本为 javax.annotation.Resource），并非 Spring 专有注解。Spring 对其提供了专门的解析器，因此它同样能被容器正确处理，但走的是一条与 @Autowired 不同的解析路径。

2. 名称优先，类型回落

@Resource 的默认策略是先按名称匹配：注解未显式指定 name 时，以字段名或 setter 方法对应的属性名作为 Bean 名称去查找；找到即注入。若按名称找不到，再回退到按类型匹配。

@Service
public class NotifyService {
    @Resource
    private SmsSender smsSender; // 先找名为 smsSender 的 Bean，找不到再按类型找
}

如果希望精确指定，可以直接写明名称：

@Resource(name = "alipayChannel")
private PayChannel payChannel;

注意，@Resource 没有 required 这类开关：解析不到目标 Bean 时会直接报错，不存在“允许为 null”的语义。这在某种程度上反而保证了依赖的确定性。

3. 构造器上的限制

@Resource 的标注位置以字段和 setter 方法为主，不支持标注在构造器参数上完成构造注入。因此在推崇构造器注入的现代写法中，@Autowired（或直接用单一构造器省略注解）更合适。

四、关键差异对照

维度	@Autowired	@Resource
提供方	Spring 框架	Java 标准注解
默认策略	按类型（byType）	按名称（byName），失败回落类型
名称指定方式	配合 @Qualifier	注解 name 属性或字段名
缺失容错	required=false 可为 null	无此开关，缺失即报错
构造器注入	支持	不支持
集合注入	支持	语义上不以此为主

从表中可以看出：@Autowired 更“Spring 原生”，表达力强、可配置面广；@Resource 更“标准化”，语义偏向按名称定位，适合依赖名称清晰稳定的场景。

五、实际选型与常见坑

1. 何时用哪个

• 推荐构造器注入 + @Autowired（或省略注解）：适用于绝大多数业务组件，依赖明确、可测试性好。
• 需要按名称精确指定时：两者皆可，@Autowired + @Qualifier 与 @Resource(name=...) 等价性较高，团队内保持统一风格即可。
• 同一类型多实现且名称即语义：@Resource 按名称优先的特性比较顺手，但要注意字段名与 Bean 名强耦合，重命名字段可能悄悄改变注入目标。
• 需要可选依赖：只能选 @Autowired(required=false)，或更推荐用条件装配注册 Bean。

2. 容易踩的坑

坑一：字段名与 Bean 名不一致导致注入错对象。 @Resource 按名称优先，若字段名恰好与某个 Bean 名匹配，即使类型上存在更“合适”的候选者，也会优先注入名称匹配的那个。

坑二：多实现类下 @Autowired 报 NoUniqueBeanDefinitionException。 这不是注解写错了，而是候选不唯一。解决方式是加 @Qualifier、给实现类起明确的 Bean 名，或改为集合注入统一遍历。

坑三：代理对象与类型匹配。 当目标 Bean 被 AOP 代理时，注入的类型匹配依赖代理方式（接口代理或类代理）。若按实现类类型注入而代理基于接口生成，就可能匹配失败。此时按接口类型注入更稳妥。

坑四：字段注入掩盖设计问题。 无论用哪个注解，字段注入都让依赖关系不易被察觉、单元测试需要依赖容器。能改构造器注入就尽量改。

六、小结

@Autowired 与 @Resource 都能完成注入，但前者是 Spring 原生的类型驱动方案，配合 required、@Qualifier、构造器与集合注入，表达能力强；后者是标准化注解，走名称优先、类型回落的解析路径，语义更贴近“按名字取 Bean”。

真正决定项目质量的，不是选了哪个注解，而是是否清楚每种装配策略的解析顺序与失败模式。把依赖关系显式化（优先构造器注入、必要时用限定符）、把可选性交给条件装配而非运行期判空，才是避免注入问题反复出现的关键。