为什么 Spring 推荐构造函数注入而非 @Autowired？

在使用 Spring 框架开发时，@Autowired 是一种简便的依赖注入方式。然而，随着项目的规模和复杂度增长，构造函数注入逐渐成为官方推荐的最佳实践。

这篇文章将分析为什么构造函数注入更优，并通过代码示例展示如何实现。

1. 使用 @Autowired 的问题

1.1 隐式依赖，降低代码可读性

@Autowired 依赖 Spring 容器的自动扫描机制，这使得依赖关系隐藏在注解之下，阅读代码时难以直观地了解类的依赖。

示例：

@Componentpublic class OrderService {
    @Autowired    private UserRepository userRepository;
    @Autowired    private NotificationService notificationService;
    public void processOrder() {        // 业务逻辑    }}

在上述代码中，OrderService 的依赖被隐式注入。代码审查时无法快速看出类需要哪些依赖，增加了理解成本。

1.2 不便于单元测试

在单元测试中，如果使用 @Autowired 注解，依赖必须由 Spring 容器管理，这让测试变得更加复杂，尤其是需要引入 Mock 对象时。

示例：

@RunWith(SpringRunner.class)@SpringBootTestpublic class OrderServiceTest {
    @Autowired    private OrderService orderService;
    @MockBean    private UserRepository userRepository;
    @MockBean    private NotificationService notificationService;
    @Test    public void testProcessOrder() {        // 测试逻辑    }}

虽然可以通过 @MockBean 实现 Mock，但这种方式将测试耦合到了 Spring 容器，而不是独立测试的理想方式。

1.3 空指针异常风险

如果 Spring 容器未正确扫描到某个依赖，@Autowired 注解不会在编译时抛出错误，而是在运行时抛出空指针异常。这种问题在大型项目中可能非常隐蔽且难以排查。

2. 推荐的构造函数注入

构造函数注入是一种更显式的方式，可以明确地声明依赖关系，并且在编译时检查依赖的完整性。这种方式比 @Autowired 更加安全、清晰，并且便于测试。

2.1 使用构造函数注入

通过构造函数注入，将依赖关系作为类的必需参数，明确暴露类的依赖。

示例：

@Componentpublic class OrderService {
    private final UserRepository userRepository;    private final NotificationService notificationService;
    // 构造函数注入    public OrderService(UserRepository userRepository, NotificationService notificationService) {        this.userRepository = userRepository;        this.notificationService = notificationService;    }
    public void processOrder() {        // 业务逻辑    }}

优点：

明确列出了类的依赖，代码更加清晰。
避免了字段级注入的空指针异常风险。
提升了代码的可测试性。

2.2 单元测试示例

构造函数注入便于在测试中手动创建对象，并注入 Mock 依赖。

import static org.mockito.Mockito.*;
public class OrderServiceTest {
    private OrderService orderService;    private UserRepository userRepository;    private NotificationService notificationService;
    @Before    public void setUp() {        userRepository = mock(UserRepository.class);        notificationService = mock(NotificationService.class);        orderService = new OrderService(userRepository, notificationService);    }
    @Test    public void testProcessOrder() {        // 测试逻辑    }}

这种方式完全脱离了 Spring 容器，使测试更加独立且灵活。

2.3 使用 Lombok 简化构造函数注入

如果项目中使用了 Lombok，可以通过 @RequiredArgsConstructor 自动生成构造函数，进一步简化代码。

示例：

@RequiredArgsConstructor@Componentpublic class OrderService {
    private final UserRepository userRepository;    private final NotificationService notificationService;
    public void processOrder() {        // 业务逻辑    }}

只需声明依赖为 final，Lombok 就会自动生成包含这些依赖的构造函数。

3. 显式 Java 配置：另一种替代方案

除了构造函数注入，还可以通过显式 Java 配置管理依赖。这种方式尤其适用于复杂场景，依赖关系清晰且完全由开发者掌控。

示例：

@Configurationpublic class AppConfig {
    @Bean    public UserRepository userRepository() {        return new UserRepositoryImpl();    }
    @Bean    public NotificationService notificationService() {        return new EmailNotificationService();    }
    @Bean    public OrderService orderService(UserRepository userRepository, NotificationService notificationService) {        return new OrderService(userRepository, notificationService);    }}

优点：

所有依赖关系都在配置类中显式定义。
避免了组件扫描带来的不确定性。
更容易控制和调试 Bean 的创建过程。

4. 总结

虽然 @Autowired 是一种方便的依赖注入方式，但在大型项目中，它的隐式性、不便于测试和空指针风险让它逐渐不再被推荐。

相比之下：

构造函数注入 是一种更显式、安全和可维护的方式。
显式 Java 配置 提供了清晰的依赖管理方法。
Lombok 可以进一步简化构造函数注入的代码。

在现代 Spring 开发中，建议优先使用构造函数注入，以提升代码的可读性和可维护性。如果你的项目中还在广泛使用 @Autowired，不妨尝试逐步迁移到更优的依赖注入方式，让代码更加健壮和易于测试。

? 大家好，我是枫哥，一名Java后端开发者！我热衷于探索新技术，并在我的微信公众号上分享关于Java 生态和后端开发的知识。

欢迎关注我的公众号，期待与你一起探讨技术的无穷可能！目前专注于Java技术分享，覆盖春招、秋招、社招和跳槽相关内容，并提供一对一带徒学习服务。

加入学徒计划，即可享受内推机会和优质资源，签订协议确保就业无忧。

此外，我们还推出了‘Java跳槽网’，为你的求职之路提供全方位支持，助你快速找到理想工作

—END—