Autowired 这个注解，只要写过 Spring 项目的 Java 工程师，基本没有不认识的。但说实话，我发现身边很多人对它的理解停留在“拿来就用”的层面——能注入成功，但遇到多个实现类报错、静态工具类注入不进去、单元测试里 null 指针这类问题，就开始凭感觉瞎试。这篇文章我打算把 Autowired 从使用到原理、从常见坑到最佳实践完整梳理一遍，既有 Spring 框架层面的原理解读，也有实际项目里沉淀下来的实战经验，不管你是刚入行的新人，还是写了两三年 Spring 的老手，应该都能从中找到点有价值的东西。
1. 内容整体设计与思路拆解
1.1 为什么会有 Autowired 这个注解
要理解 Autowired，得先从 Spring 的核心思想说起。Spring 容器就像一个中央仓库，你把自己写的类交给它管理（通过 @Component、@Service、@Repository 这类注解），容器负责创建实例、初始化属性、管理生命周期。但类与类之间经常需要互相协作，比如 OrderService 要调用 UserMapper，那 OrderService 内部就得持有一个 UserMapper 的引用。
在没有 Spring 的年代，你只能在 OrderService 里自己 new 一个 UserMapper，或者在构造方法里传参。自己 new 的问题在于：类与类之间耦合得太死，想换一个实现类或者加一层代理，得改代码重新编译。Autowired 干的事情，就是把这层依赖关系交给 Spring 容器来“自动装配”，你只需要声明“我需要一个 UserMapper”，容器会在启动阶段扫描、匹配，然后把现成的实例给你送过来。
这个过程用大白话讲，就是 Spring 容器在启动时看到你标注了 @Autowired 的字段或方法，它会拿着这个字段的类型去容器里找匹配的 Bean，找到就注入，找不到或者找到多个就按特定规则处理。这也是为什么大家经常说 Autowired 是“按类型自动装配”。
1.2 Autowired 能解决什么问题
核心解决的问题就一个：依赖注入的自动化。它能让你少写大量 getter/setter 和构造方法的样板代码，同时让类与类之间保持松耦合。你定义接口，然后通过 Autowired 把接口的实现类注入进来，哪天要换实现，改配置或者改标注，不需要动业务调用代码。
它还支持一些灵活的场景。你可以注入单个 Bean，也可以注入 List、Map 这种集合类型，把同一接口的所有实现类一次性装进来，这在策略模式的场景下特别好用。你还可以配合 @Qualifier 指定具体注入哪一个实现，配合 @Primary 指定默认优先注入哪个，配合 @Value 注入配置文件里的值（虽然 @Value 和 Autowired 不是一回事，但在很多项目里它们经常一起出现，都是“依赖注入”这个大家族里的成员）。
1.3 这篇文章适合谁来读
如果你是刚接触 Spring 的初学者，这篇文章能帮你理清 @Autowired 的三种注入方式、底层匹配逻辑，让你知道为什么照着例子写能跑通，改一改就报错。如果你是有一定经验的开发者，重点可以看第 4 节和第 5 节——多实现类场景的处理、Autowired 和 Resource 的区别、静态工具类注入问题的解决方案，这些是从“会用”走向“用好”必须跨过的坎。
2. 核心细节解析与实操要点
2.1 三种注入方式：字段注入、Setter 注入、构造器注入
Autowired 可以用在三个地方：字段上、Setter 方法上、构造器上。这是最基础的知识，但三种方式各自的利弊，很多人没细想过。
字段注入是使用频率最高的一种，代码最简洁：
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private UserService userService; }优点一目了然：省事，不写构造方法，不写 setter。但缺点也很明显——依赖关系被“藏”在私有字段里，外部看不到，单元测试的时候想手动 new 一个 OrderService 再传 mock 对象进去，都不太方便（除非用 ReflectionTestUtils 这种工具）。更关键的是，字段注入的类在 Spring 容器之外几乎无法使用，它把“Spring 容器必须存在”这个前提强加给了这个类，违反了依赖注入“最小化框架依赖”的思想。
Setter 注入是这样的：
@Service public class OrderService { private OrderMapper orderMapper; @Autowired public void setOrderMapper(OrderMapper orderMapper) { this.orderMapper = orderMapper; } }这种方式的灵活性在于依赖可以在对象创建之后再“重新设置”，理论上支持运行时替换某个依赖。但实际开发中用得不多，因为 Spring 容器启动后 Bean 基本是单例、不变的，这种动态替换的场景少之又少。
构造器注入是我目前最推荐的方式：
@Service public class OrderService { private final OrderMapper orderMapper; public OrderService(OrderMapper orderMapper) { this.orderMapper = orderMapper; } }注意构造器注入其实可以省略 @Autowired 注解——Spring 4.3 之后，如果类只有一个构造方法，容器会隐式使用它来完成注入。构造器注入的好处是依赖在对象创建时就必须全部准备好，Bean 永远处于“完整可用”的状态，不会出现依赖为 null 的情况。同时，因为是 final 字段，还可以防止依赖被意外替换。
实测下来，我后来把新项目里的字段注入全部改成了构造器注入。除了上面说的可测试性和不可变性，还有一个很现实的场景：当一个类的依赖太多时，字段注入你不会察觉问题，因为所有 @Autowired 散落在各个字段上，一眼扫过去根本看不清这个类到底依赖了哪些东西。而用构造器，当参数超过 6 个时 IDE 会给你黄色警告，这是重构的信号。
2.2 底层匹配逻辑：为什么我只写一个注解就能拿到想要的 Bean
Autowired 的默认匹配规则是byType（按类型）。Spring 容器在启动时会为每个 Bean 建立一个 BeanDefinition，其中包含了这个 Bean 的类型信息。当容器处理到某个 Autowired 字段时，它会执行这样一个流程：
- 根据字段类型，去容器中找到所有符合这个类型的 Bean。
- 如果结果为空，再看 @Autowired 的 required 属性是否为 true（默认是 true），如果是 true，则抛出 NoSuchBeanDefinitionException，启动失败。
- 如果结果只有一个，直接返回。
- 如果结果有多个，则尝试按名称匹配（字段名和 Bean 名称一致），匹配到就返回。
- 如果按名称也匹配不上，再看是否有 @Primary 标注的候选者，有就用它。
- 如果以上都不行，抛出 NoUniqueBeanDefinitionException。
第 4 步很多人不理解，举一个具体例子：如果你有一个接口UserService，有两个实现类UserServiceImpl和UserServiceMock，在容器里默认的 Bean 名称就是类名首字母小写，也就是userServiceImpl和userServiceMock。如果你的字段名恰好叫userServiceImpl：
@Autowired private UserService userServiceImpl;这种情况下 Spring 会尝试按名称userServiceImpl去匹配，嘿嘿，还真能匹配上，所以不会报错。这是个很隐蔽的行为，很多人遇到多实现类报错时随便改字段名碰运气，其实就是碰上了第 4 步的规则。但我不建议依赖这种方式，太隐晦，可读性差。
2.3 required 属性与可选依赖的处理
@Autowired 有一个required属性，默认是 true 表示必须注入成功，容器里找不到对应 Bean 时直接启动失败。如果你希望某个依赖是可选的——比如在某些环境有该 Bean 就用它，没有就继续启动——可以把 required 设为 false：
@Service public class ReportService { @Autowired(required = false) private DataSource dataSource; }但这里有个坑，如果容器里有多个 DataSource 实现，required=false 并不会帮你跳过冲突，多个候选者的情况下该抛异常还是抛异常。required=false 只在“一个候选都没有”时才生效。所以它适合那种“有就用、没有拉倒”的场景，典型例子是对接一些可选的监控组件、可选的缓存客户端。
Java 8 之后还有两种更优雅的可选依赖写法：用java.util.Optional包裹，或者用@Nullable标注参数。Optional 的方式在字段注入和构造器注入里都能用：
@Service public class ReportService { private final DataSource dataSource; public ReportService(Optional<DataSource> dataSource) { this.dataSource = dataSource.orElse(null); } }这种写法比 required=false 要清晰得多，因为它是显式声明“这个依赖可能不存在，你需要自己处理缺省逻辑”。
3. 实操过程与核心环节实现
3.1 环境准备：一个最小的 Spring 项目
动手之前先准备环境。我用的是最经典的 Maven + Spring Boot 2.7 的组合，JDK 1.8 以上都行。Spring Boot 的好处是自动配置已经把大部分事情干完了，我们只需要关注业务代码。如果是纯 Spring 项目（没有 Spring Boot），需要手动引入 spring-context 依赖并配置注解扫描，逻辑是一样的，不过 Spring Boot 确实省心不少。
创建一个最简单的项目结构：
src/main/java └── com/example/demo ├── DemoApplication.java ├── controller ├── service ├── dao └── configDemoApplication 是启动类，用 @SpringBootApplication 标注，它默认扫描的包是当前类所在的包以及子包。这一步很关键，很多人 Autowired 注入不进去，排查到最后发现是 @ComponentScan 没扫到对应的包。
3.2 一个完整的字段注入例子
假设现在要做一个订单服务，它需要依赖一个订单查询的 Mapper 和一个用户信息服务。先定义两个 Bean：
@Repository public class OrderMapper { public List<Order> listOrders() { // 模拟查库 return new ArrayList<>(); } }@Service public class UserService { public String getUserName(Long userId) { return "用户" + userId; } }然后在 OrderService 里用 @Autowired 注入它们：
@Service public class OrderService { @Autowired private OrderMapper orderMapper; @Autowired private UserService userService; public void printOrderInfo(Long orderId, Long userId) { System.out.println(orderMapper.listOrders()); System.out.println(userService.getUserName(userId)); } }从本质上讲，Spring 启动时做了三件事：扫描到 OrderMapper、UserService、OrderService 三个 Bean，把这些 Bean 的实例创建好存到容器里，然后把 OrderMapper 和 UserService 的实例“塞”进 OrderService 的字段里。整个过程对开发者是透明的，这就是“自动装配”名字的由来。
3.3 多实现类场景：如何指定注入目标
接口多实现是实际项目里最常遇到的问题。比如一个短信发送接口：
public interface SmsSender { void send(String phone, String content); }两个实现：
@Component public class AliyunSmsSender implements SmsSender { @Override public void send(String phone, String content) { System.out.println("阿里云发送短信给" + phone); } }@Component public class TencentSmsSender implements SmsSender { @Override public void send(String phone, String content) { System.out.println("腾讯云发送短信给" + phone); } }直接这样注入会报 NoUniqueBeanDefinitionException：
@Autowired private SmsSender smsSender;因为容器里有两个 SmsSender 类型的 Bean，Spring 不知道选哪个。解决办法有三种：
第一种，用 @Qualifier 指定 Bean 名称：
@Autowired @Qualifier("aliyunSmsSender") private SmsSender smsSender;这里的字符串“aliyunSmsSender”就是 AliyunSmsSender 类名首字母小写后的名称。这种做法的好处是指定精确，坏处是字符串和 Bean 名称是硬编码，如果哪天类名改了，这里不报编译错误但运行会报错。
第二种，用 @Primary 指定默认优先候选者：
@Component @Primary public class AliyunSmsSender implements SmsSender { // ... }这样直接 @Autowired 注入时，Spring 会优先选择带 @Primary 的那个。但这个方案有一个隐含问题：如果你在别的地方真的想注入腾讯云的实现，光靠 @Autowired 就不行了，还是得再加 @Qualifier 显式指定。
第三种，注入所有实现类，策略模式典型玩法：
@Service public class SmsService { private final Map<String, SmsSender> senderMap; public SmsService(Map<String, SmsSender> senderMap) { this.senderMap = senderMap; } public void send(String type, String phone, String content) { SmsSender sender = senderMap.get(type); if (sender == null) { throw new IllegalArgumentException("不支持的短信渠道: " + type); } sender.send(phone, content); } }这里 Map 的 key 就是 Bean 名称（aliyunSmsSender / tencentSmsSender），value 是对应实例。这样在业务层通过渠道类型直接选择使用哪家供应商，扩展新渠道时只需要加实现类，业务代码不用改。这是我特别推荐的项目实践，比在业务逻辑里写一堆 if/else 要优雅得多。
实际项目里我还遇到过更复杂的场景：某些短信渠道只在特定环境启用，比如只在生产环境接入腾讯云，测试环境只保留阿里云。这时候可以在实现类上加 @ConditionalOnProperty(name = "sms.aliyun.enabled", havingValue = "true") 这类条件注解，让 Bean 按环境动态注册。这样的好处是容器里根本不存在的 Bean，也就不会出现多候选人冲突的问题了。
3.4 构造器注入与 Lombok 结合的最佳实践
构造器注入搭配 Lombok 是现在新项目的标配写法。Lombok 的 @RequiredArgsConstructor 会根据 final 字段自动生成构造方法：
@Service @RequiredArgsConstructor public class OrderService { private final OrderMapper orderMapper; private final UserService userService; }这段代码能省略一个看起来很啰嗦的构造方法，Spring 会通过构造器注入把 OrderMapper 和 UserService 传进来。类上不需要写 @Autowired，因为前面说过，单构造方法会自动参与注入。
我现在搭建新项目基本都用这套组合：@Service + @RequiredArgsConstructor + private final 字段。读到代码的人一眼就能看出这个类的依赖有哪些，而且因为字段是 final，后续想改都改不了，强制保证依赖不被篡改。
3.5 测试环境下的注入处理
测试类是 Autowired 使用中容易被忽视的场景。很多人写单元测试时用了 @SpringBootTest，然后在测试类里 @Autowired 注入真实的 Service 和 Mapper：
@SpringBootTest public class OrderServiceTest { @Autowired private OrderService orderService; @Test public void testPrintOrderInfo() { orderService.printOrderInfo(1L, 1L); } }这样能跑通的前提是测试环境有完整的数据库连接、Redis 连接等基础设施。如果只是想测一个类的业务逻辑，最好用 Mockito 把外部依赖 mock 掉，并配合构造器注入把 mock 对象传进去：
public class OrderServiceTest { private OrderService orderService; @Mock private OrderMapper orderMapper; @BeforeEach public void setUp() { MockitoAnnotations.openMocks(this); orderService = new OrderService(orderMapper, null); } }这里可以看出构造器注入对单元测试巨大的帮助：依赖可以手动控制，不需要启动整个 Spring 容器，测试速度飞快。如果你的类都用字段注入，这种轻量级的测试写法基本没法弄。
4. 常见问题与排查技巧实录
4.1 多实现类冲突：NoUniqueBeanDefinitionException
这是 @Autowired 最常见的报错。报错信息长这样：
No qualifying bean of type 'com.example.demo.SmsSender' available: expected single matching bean but found 2: aliyunSmsSender,tencentSmsSender解决方案前面已经讲过，要么加 @Qualifier，要么用 @Primary，要么改成注入 List/Map。我的排查顺序是：先看报错信息里列出了哪些候选 Bean 名称，确认自己真正想注入的是哪一个，再决定用哪种方式。
排查技巧：如果用了 @Primary 但注入的还是错，看看是不是有多个类都标了 @Primary，或者某个被 @Qualifier 指定了另外一个名字。另外还要留意，Spring Boot 的自动配置类中可能也有一些你意想不到的候选者，比如 DataSource 相关的注入，会遇到好几种连接池类型，这需要结合 startup 日志逐一看。
4.2 注入为 null 的本质原因：Bean 没有被容器管理
很多人在工具类、配置类、过滤器、拦截器里使用 @Autowired 时发现注入进来的对象是 null，排查了半天，最后发现那个类根本不在 Spring 容器里。举个例子：
public class JwtUtils { @Autowired private JwtProperties jwtProperties; public String generateToken() { // 这里 jwtProperties 是 null } }如果 JwtUtils 是直接 new 出来的，@Autowired 根本不会生效——Spring 的依赖注入只发生在它管理的 Bean 身上。解决方案是让这个类也成为 Bean，比如加 @Component 注解，或者在配置类里用一个 @Bean 方法返回这个实例。
这类问题的排查思路可以固定成一条路径：先检查类上有没有 @Component/@Service/@Repository/@Controller 这类的注解，再检查这类是否在组件扫描的包路径下，最后检查是否在配置类中被 @Bean 显式声明。三层检查下来，80% 的 null 问题都能定位。
4.3 循环依赖：启动报错 Requested bean is currently in creation
循环依赖是指 A 依赖 B，B 又依赖 A。在 Spring 中，如果 A 和 B 都是单例 Bean，并且用的是 setter 或字段注入，Spring 可以三级缓存机制来解决一部分循环依赖。但如果是构造器注入，启动时会直接报错：
BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation这个问题的本质是：构造器注入要求依赖在对象创建时就必须就绪，但 A 要先创建出实例才能注入给 B，B 要创建出实例才能注入给 A，两者互相等待，形成了死锁。而字段注入和 setter 注入允许先创建空壳对象再填充依赖，配合 Spring 的三级缓存就能打破循环。
实际项目里遇到循环依赖，我很少推荐去调整注入方式绕过去。循环依赖本身说明你的设计出了问题——两个类职责纠缠不清。最好的做法是识别出其中一个依赖到底要用什么职责，把公共部分拆到第三个类里，或者用事件机制解耦。改了一段结构之后你会发现，循环依赖消失的同时，代码也更容易读了。
4.4 @Autowired 与构造器注入不能混用的情况
有一个细节容易踩坑：一个类写了两个构造方法，其中只有带参数的构造方法标注了 @Autowired，另一个是无参构造器。这种情况下，Spring 使用带 @Autowired 的构造器，没有 @Autowired 的那个不会作为注入入口，但如果你手动 new 这个类，Java 语法层面会调用无参构造器。这会造成一个微妙的差异：容器中的 Bean 依赖是完整的，而手动 new 的对象所有依赖都是 null。所以建议只在“单一构造器”的类里使用构造器注入，避免这种困惑。
4.5 常见问题速查表
| 现象 | 常见原因 | 解决方案 |
|---|---|---|
| 启动报 NoSuchBeanDefinitionException | 容器中没有该类型的 Bean，或组件未被扫描到 | 加 @Component/@Service，或检查包扫描路径 |
| 启动报 NoUniqueBeanDefinitionException | 接口有多个实现类，未指定注入目标 | @Qualifier / @Primary / 注入 List 或 Map |
| 注入的字段为 null | 类不是 Spring Bean，或直接 new 了对象 | 让类交给 Spring 管理，避免手动 new |
| 启动报 BeanCurrentlyInCreationException | 存在循环依赖，且用了构造器注入 | 重新设计职责拆分，或改用字段/setter 注入 |
| 单元测试里注入为 null | 测试类没有启动 Spring 容器 | 加 @SpringBootTest，或手动 mock 依赖 |
| 多个构造器导致注入结果不确定 | 类有多个构造方法且都没加 @Autowired | 只保留一个构造器，或在需要注入的构造器上显式标注 |
4.6 日志定位技巧
当注入问题时，不要只盯着代码看。Spring 启动日志里包含 Bean 的注册信息，把日志级别调到 DEBUG 后，可以搜索 “Creating shared instance of singleton bean” 相关的输出，能看到容器创建了哪些 Bean、在创建哪个 Bean 时挂了。对于 NoSuchBeanDefinitionException，报错信息前几行会提示它正在解析哪个类、字段名叫什么，顺着这个线索往上查具体配置或者扫描范围，通常很快能定位。
5. 对比其他依赖注入注解：Autowired、Resource、Inject
5.1 三者的使用差异
先说 @Resource：它在 javax.annotation 包里，是 Java 标准规范里的注解（Jakarta EE），不是 Spring 独有的。@Resource 默认按名称注入，如果按名称找不到，再按类型找。而 @Autowired 默认按类型注入，按类型找不到多个候选时再按名称匹配。这个差异会导致行为不一样。
比较典型的情况：
@Resource private SmsSender aliyunSmsSender;@Resource 会直接按名字aliyunSmsSender去容器里找，找到就注入，不会管容器里有多少个 SmsSender 类型。而 @Autowired 会先按类型找，发现多个候选者后再尝试按名称匹配。看似殊途同归，但匹配顺序不同，报错时机和报错信息也完全不同。
@Inject 是 JSR-330 规范里的注解，需要额外引入 javax.inject 依赖（Spring Boot 自带该依赖）。它的用法和 @Autowired 基本一致，也支持构造器、字段、setter，配合 @Named 注解可以起到类似 @Qualifier 的作用。Spring 官方对它的评价是“与 Spring 的 @Autowired 具有完全相同的语义”，所以用哪个更多是团队习惯问题。
5.2 实际项目中的选择建议
从实用角度讲，@Resource 在“按名称注入”的场景下比 @Autowired + @Qualifier 更简洁，不需要额外写一个字符串。而且它是 Java EE 的标准规范，如果有一天项目要迁移到别的依赖注入框架（比如 Guice），@Resource 的兼容性更好。
但 @Autowired 有一个明显优势：它对 Java 8 的 Optional、集合类型注入（List/Map）、@Primary 的支持非常完善，这些能力 @Resource 并不完全具备。如果你在项目里用了很多策略模式、集合注入等高级玩法，@Autowired 是更顺手的工具。
我自己的选择标准很简单：
- 新项目统一用 @Autowired + 构造器注入，因为这是 Spring 生态最“正宗”的玩法。
- 如果某些地方就是需要按名称注入且只有一个字符串场景，我会考虑 @Resource。
- 尽量不在同一个类里混用两种注解，否则后续维护的人看代码会很分裂。
5.3 与 @Value 的区别
有人容易把 @Autowired 和 @Value 混在一起。@Autowired 注入的对象是容器里的 Bean 实例，比如一个 UserService 对象、一个 DataSource 连接池对象；@Value 注入的是配置文件里的字符串、数字等字面量，比如@Value("${server.port}")拿到的就是 8080。两者虽然都叫“注入”，但一个是对象引用，一个是配置值，使用场景完全不同。在构造器注入的场景里，两者经常配合使用：
@Service @RequiredArgsConstructor public class OrderService { private final OrderMapper orderMapper; @Value("${order.timeout}") private int timeout; }这里要注意：@RequiredArgsConstructor 只处理 final 字段，@Value 字段一般不是 final，所以 Lombok 不会给它生成构造参数。这个细节初学容易踩，特地说一下。
6. 常见误用纠正与进阶经验总结
6.1 不要在一个类里堆积无限制的依赖
字段注入太省事，导致很多同学图省事把一个类的依赖越加越多。当一个类有七八个甚至十几个依赖时，它的职责一定过重了。构造器注入最直接的价值就在这里：它通过 IDE 的参数数量警告，把“这个类要重构了”的信号直接摆在你面前。
实际项目里我见过一个 2000 多行的 Service 类，构造器参数有 18 个，每次新建这个类的人都被吓一跳。后来我们把里头的几个职责拆出去，拆分后每个类依赖都降到了 3 到 4 个，代码立马清爽了。依赖数量本身就是一个设计指标，用好构造器注入，相当于给这个指标装了仪表盘。
6.2 静态工具类里的注入解决方案
有些场景需要在静态方法里访问依赖，比如一个全局的 MD5 工具类里想要注入一个密钥配置对象。简单粗暴地给静态字段加 @Autowired 是无效的：
@Component public class EncryptUtil { @Autowired private static EncryptProperties encryptProperties; public static String encrypt(String content) { // encryptProperties 是 null } }Spring 不会为静态字段执行注入。通用解法是把静态字段通过一个实例方法赋值：
@Component public class EncryptUtil { private static EncryptProperties encryptProperties; @Autowired public void setEncryptProperties(EncryptProperties encryptProperties) { EncryptUtil.encryptProperties = encryptProperties; } public static String encrypt(String content) { return encryptProperties.encrypt(content); } }原理很朴素：Spring 常规地对实例方法做注入，实例方法把收到的参数赋值给静态字段。不过还要注意一个点：这个工具类本身必须被 Spring 扫描到，否则 setter 方法永远不会被调用。
这个方案有个隐藏问题：单元测试跑这个静态方法时，encryptProperties 可能还是 null，因为静态字段不随普通对象销毁而重置。解决方式是提供静态的 setter 方法供测试代码设置 mock 值。虽然不完美，但相比引入静态 ServiceLocator 之类的模式，这个方案简单直接，维护成本低。
6.3 使用 final 与不可变性的好处
构造器注入配合 final 字段，能保证依赖在对象创建后不变，这在多线程环境下特别重要。Spring 容器里的大多数 Bean 都是单例的，会被多个线程共享。如果依赖可以被随意 setter 替换，并发场景下就可能出现某个线程修改了依赖、其他线程用到不同实现的问题。final 字段从语言层面杜绝了这种隐患。
这虽然是“最佳实践”层面的内容，但它不属于教条。我在一个并发较高的业务系统里，就亲眼看到过有人用 setter 注入在运行时动态切换数据源，结果线上频繁出现连接错乱。改成构造器 + final 后，这类问题直接绝迹。
6.4 多个实现类下的优雅设计模式
多实现类冲突是 Autowired 的高频问题，这里补充一个工厂模式 + Map 注入的进阶玩法。还是以 SmsSender 为例，在 @Configuration 配置类里通过 @Bean 手动注册，可以自定义 Bean 名称，这在动态替换或条件装配时特别有用：
@Configuration public class SmsConfig { @Bean("smsAliyun") public SmsSender aliyunSmsSender() { return new AliyunSmsSender(); } @Bean("smsTencent") public SmsSender tencentSmsSender() { return new TencentSmsSender(); } }然后注入 Map：
@Service public class SmsSenderFactory { private final Map<String, SmsSender> senders; public SmsSenderFactory(Map<String, SmsSender> senders) { this.senders = senders; } public SmsSender getSender(String type) { SmsSender sender = senders.get(type); if (sender == null) { throw new IllegalArgumentException("不支持的短信渠道: " + type); } return sender; } }这样连 @Qualifier 都不用写，业务调用方只需要知道渠道类型字符串就行。而且后续扩展新渠道，只需要新增实现类和配配置项，SmsSenderFactory 一行不用改。
6.5 启动慢时如何排查注入相关性能问题
有一种情况比较容易忽略：项目功能正常、启动也没有报错，但启动速度很慢。这时除了排查数据库连接池初始化之外，还要看一眼是不是因为 @Autowired 注入的依赖触发了大量懒加载 Bean 的初始化。某些 Bean 配置了 @Lazy，但如果注入时没有同步标注 @Lazy，启动时依然会被提前创建。
如果确实需要延迟某个重量级 Bean 的初始化，可以这样组合：
@Autowired @Lazy private ReportClient reportClient;这样容器创建 ReportClient 的实例会推迟到第一次使用时。注意这里 @Lazy 注解和 @Autowired 是独立的两个注解，配合使用才能生效。
最后再分享一个小技巧：如果你在 IDEA 里开发，装了 Alibaba Java Coding Guidelines 插件之后，它会直接给字段注入打上黄色警告，提示你优先使用构造器注入。团队里推广最佳实践时，与其反复在 Code Review 里提，不如让 IDE 在写代码的那一刻就给反馈，这个效果真的好很多。
根据我个人这几年的经验，@Autowired 虽然只是一个注解，但它背后是 Spring 框架“面向接口、控制反转、依赖注入”这一整套设计思想的浓缩。把它的匹配规则、注入方式、多实现类处理这些细节吃透，你写的东西会慢慢从“能跑”变成“好维护、好测试、好扩展”。希望这篇文章里记录的那些教训和思路，能在你踩坑之前先帮你避开几次。
