🏡 博客首页：IT 派同学
⛳️ 欢迎关注 🐳 点赞 🎒 收藏 ✏️ 留言
🎢 本文由 IT 派同学原创编撰
🚧 系列专栏：《SpringBoot入门宝典》
🎈 本系列主要输出作者自创的开源项目
🔗 作品：前往《 AI 捣蛋屋》, 体验最新AI技术的平台，提供AI论文写作、多功能GPT智能体、智能UI生成以及计算机课程设计源码服务，助力学术研究与开发效率提升。
作为Java程序员，Spring绝对是我们日常开发中使用频次最高的框架之一。它灵活的依赖注入机制为我们开发高可维护性的代码提供了极大的便利。然而，尽管@Autowired注解让依赖注入变得如此简单，Spring官方却明确不推荐在字段上使用它进行注入。那么，为什么会这样？今天，我们就来深入探讨一下这个问题。
@Autowired字段注入的现状
@Autowired是Spring框架中非常常见的注解，用于自动注入依赖。当我们在类的字段上标注这个注解时，Spring会自动将所需的依赖注入进来。这种方式的确简单明了，代码也相对简洁：
@Component
public class MyService {
@Autowired
private UserRepository userRepository;
public void performOperation() {
// 使用 userRepository 执行一些操作
}
}
这段代码看起来非常干净和直接，我们只需要在字段上加上@Autowired注解，Spring就会帮我们处理依赖注入。然而，从Spring 4.0开始，官方就不推荐这种字段注入方式了。那么问题出在哪里？
字段注入的风险与缺点
-
难以进行单元测试
字段注入的一个主要问题是它在单元测试中并不友好。在测试环境中，如果你不使用Spring`上下文，那么你需要手动通过反射来注入依赖，这使得测试代码变得复杂且脆弱。例如：
public class MyServiceTest { private MyService myService; @BeforeEach void setUp() { myService = new MyService(); UserRepository userRepository = mock(UserRepository.class); // 手动注入依赖（通常通过反射） ReflectionTestUtils.setField(myService, "userRepository", userRepository); } @Test void testPerformOperation() { // do something.... // 具体代码就不细写了, 重在讲解 } }如你所见，手动注入依赖不仅增加了测试的复杂度，还可能导致测试代码的维护成本大大增加。相比之下，构造器注入更为简洁和易测试。
-
违反单一职责原则
当我们通过字段注入依赖时，类的依赖关系变得不那么明确。换句话说，类的构造函数不再明确表达它所依赖的对象。随着项目复杂度的增加，这种隐式的依赖关系可能会导致设计上的混乱，违背单一职责原则。
案例分析：
@Component public class OrderService { @Autowired private PaymentService paymentService; @Autowired private ShippingService shippingService; @Autowired private NotificationService notificationService; public void placeOrder(Order order) { paymentService.processPayment(order); shippingService.shipOrder(order); notificationService.sendNotification(order); } }在这个示例中，
OrderService显然依赖了多个服务，这可能表明它承担了过多的职责。通过构造器注入，我们可以更容易地发现这些依赖关系，从而更容易识别出类是否违反了单一职责原则。 -
容易引发NPE（空指针异常）
使用
@Autowired进行字段注入时，Spring容器在实例化对象后才会进行依赖注入。这意味着，如果我们在类的构造函数中或其他初始化代码中访问了这些尚未注入的字段，可能会导致空指针异常（NPE）。例如：@Component public class UserService { @Autowired private UserRepository userRepository; public UserService() { // 如果此时访问 userRepository，会抛出 NPE System.out.println(userRepository.findAll()); } }这种问题在开发过程中非常常见，特别是当类的构造函数或
@PostConstruct方法中需要访问这些依赖时。构造器注入可以有效避免这个问题，因为依赖项在对象创建时就已经注入完毕。
为什么Spring推荐构造器注入？
既然字段注入存在这么多问题，Spring官方为什么推荐构造器注入呢？这里有几个原因：
-
增强代码的可读性和维护性
构造器注入使得类的依赖关系一目了然。当我们看到一个类的构造函数时，就能明确知道这个类需要哪些依赖项。这不仅提高了代码的可读性，也使得依赖管理更加明确，符合单一职责原则。
@Component public class OrderService { private final PaymentService paymentService; private final ShippingService shippingService; private final NotificationService notificationService; @Autowired public OrderService(PaymentService paymentService, ShippingService shippingService, NotificationService notificationService) { this.paymentService = paymentService; this.shippingService = shippingService; this.notificationService = notificationService; } public void placeOrder(Order order) { paymentService.processPayment(order); shippingService.shipOrder(order); notificationService.sendNotification(order); } }通过构造器注入，我们可以直观地看到
OrderService依赖于PaymentService、ShippingService和NotificationService，而且这些依赖项都是不可变的。 -
方便单元测试
构造器注入使得单元测试变得更加简单和直观。我们只需在测试中传递模拟的依赖项即可，而不需要依赖
Spring上下文或反射来进行依赖注入。这大大简化了测试代码，并提高了测试的稳定性。public class OrderServiceTest { private OrderService orderService; private PaymentService paymentService; private ShippingService shippingService; private NotificationService notificationService; @BeforeEach void setUp() { paymentService = mock(PaymentService.class); shippingService = mock(ShippingService.class); notificationService = mock(NotificationService.class); orderService = new OrderService(paymentService, shippingService, notificationService); } @Test void testPlaceOrder() { // do something.... // 具体代码就不细写了, 重在讲解 } }这种方式不仅让测试代码更加清晰，也使得依赖关系更加明确和易于管理。
-
避免
NPE问题如前所述，构造器注入确保了依赖项在对象创建时即被注入，避免了使用未初始化的依赖项所引发的空指针异常。构造器注入也意味着所有的依赖都是显式传入的，因此不会因为依赖的缺失或注入顺序的问题而导致运行时错误。
-
避免循环依赖
虽然构造器注入可以避免许多字段注入的问题，但它仍然可能引发循环依赖的问题。循环依赖是指
A类依赖于B类，而B类又依赖于A类。构造器注入下，这种情况会导致Spring无法实例化这两个类。为了避免这种问题，可以通过以下几种方式来处理：- 重构代码：重新设计类之间的依赖关系，消除循环依赖。
- 使用
@Lazy注解：将其中一个依赖延迟加载，避免循环依赖的发生。
java复制代码@Component public class ClassA { private final ClassB classB; @Autowired public ClassA(@Lazy ClassB classB) { this.classB = classB; } } @Component public class ClassB { private final ClassA classA; @Autowired public ClassB(ClassA classA) { this.classA = classA; } }在上面的代码中，通过
@Lazy注解，将ClassB的依赖延迟加载，从而避免了循环依赖的问题。
重构一个Spring项目中的依赖注入
为了更好地理解构造器注入的优势，我们来实践一下如何将一个使用字段注入的Spring项目重构为使用构造器注入，示例代码如下：
@Component
public class UserService {
@Autowired
private UserRepository userRepository;
@Autowired
private NotificationService notificationService;
public void registerUser(User user) {
userRepository.save(user);
notificationService.sendNotification(user);
}
}
这个类通过字段注入依赖UserRepository和NotificationService，虽然代码看起来简洁，但如前所述，这种方式可能引发一系列问题。
对上述代码进行重构：
@Component
public class UserService {
private final UserRepository userRepository;
private final NotificationService notificationService;
@Autowired
public UserService(UserRepository userRepository, NotificationService notificationService) {
this.userRepository = userRepository;
this.notificationService = notificationService;
}
public void registerUser(User user) {
userRepository.save(user);
notificationService.sendNotification(user);
}
}
在重构后的代码中，我们通过构造器注入将依赖显式地传递给UserService，使得依赖关系更加清晰。同时，这种方式也增强了类的不可变性，并减少了潜在的NPE风险。
测试代码的改进：
通过构造器注入，我们的测试代码也变得更加直观和易于管理：
public class UserServiceTest {
private UserService userService;
private UserRepository userRepository;
private NotificationService notificationService;
@BeforeEach
void setUp() {
userRepository = mock(UserRepository.class);
notificationService = mock(NotificationService.class);
userService = new UserService(userRepository, notificationService);
}
@Test
void testRegisterUser() {
// 测试 UserService 的 registerUser 方法
}
}
通过这种方式，我们可以在不依赖Spring容器的情况下轻松编写单元测试，提高了代码的可测试性和稳定性。
总结如下
虽然@Autowired字段注入简单易用，但它在代码可读性、可维护性和测试性方面存在一些严重的缺陷。Spring官方推荐使用构造器注入，因为它能够提高代码的清晰度，减少NPE的发生，并且更利于单元测试。
而且在实际开发中，我们也应该尽量遵循这些最佳实践，通过构造器注入来增强代码的健壮性和可维护性。如果你还在使用字段注入，不妨可以尝试将你的代码重构为构造器注入，通过实践来看看它带来的好处。
扫一扫
2051
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
