Spring依赖注入：三雄争霸，谁主沉浮？@Autowired vs @Resource vs 隐形冠军Final

前言：一个幸福的烦恼

作为一名Java后端开发者，Spring的依赖注入是我们每天都要打交道的功能。记得刚学Spring时，我就像走进了一家琳琅满目的糖果店：

• @Autowired：Spring家的招牌糖果
• @Resource：JSR-250标准糖果
• 还有最近流行的final + @RequiredArgsConstructor神秘组合

这么多选择，我该pick谁？今天，就让我们一起来解开这个甜蜜的烦恼！

第一章：传统豪强——@Autowired和@Resource

@Autowired：Spring的亲儿子

@Service
public class UserService {
    @Autowired // 简单粗暴，直接上场
    private UserRepository userRepo;
    
    // 或者通过setter方法
    @Autowired
    public void setUserRepo(UserRepository userRepo) {
        this.userRepo = userRepo;
    }
}

@Autowired是Spring框架的亲儿子，默认按类型（byType）进行装配。当有多个相同类型的bean时，就需要@Qualifier注解来指定具体装配哪个bean。

@Resource：Java的标准兵

@Service
public class UserService {
    @Resource(name = "userRepository") // 按名称来装配
    private UserRepository userRepo;
}

@Resource是Java自带的注解（JSR-250），默认按名称（byName）进行装配。如果找不到名称匹配的bean，才会退回到按类型装配。

传统方式的痛点

这两种方式虽然简单，但存在几个问题：

1. 可变性：字段不是final的，理论上可以在任何时候被修改（虽然我们通常不会这么做）
2. 测试困难：需要借助反射机制来注入依赖，写测试用例时很麻烦
3. 隐藏的依赖：无法一眼看出这个类有哪些依赖

第二章：新晋王者——final + @RequiredArgsConstructor

什么是构造器注入？

在我们介绍新王者之前，先要了解什么是构造器注入：

@Service
public class UserService {
    private final UserRepository userRepo;
    private final EmailService emailService;
    
    // 手动编写构造器
    public UserService(UserRepository userRepo, EmailService emailService) {
        this.userRepo = userRepo;
        this.emailService = emailService;
    }
}

Spring会智能地找到这个构造器，并自动传入所需的依赖。但手动写构造器很麻烦，尤其是依赖很多的时候...

Lombok来拯救世界！

这时候，Lombok的@RequiredArgsConstructor就派上用场了：

@Service
@RequiredArgsConstructor // 一个注解代替所有！
public class UserService {
    private final UserRepository userRepo;
    private final EmailService emailService;
    // 不需要手动写构造器了！
}

编译后，Lombok会自动生成这样的代码：

@Service
public class UserService {
    private final UserRepository userRepo;
    private final EmailService emailService;
    
    // Lombok自动生成的构造器
    public UserService(UserRepository userRepo, EmailService emailService) {
        this.userRepo = userRepo;
        this.emailService = emailService;
    }
}

为什么这是王者之道？

1. 不可变性：final关键字保证了依赖一旦注入就无法更改，线程安全杠杠的！
2. 完全初始化：要么所有依赖都成功注入，要么干脆启动失败，没有中间状态
3. 测试友好：写单元测试时，直接通过构造器传入mock对象，简单明了
4. 代码简洁：不需要一堆注解，代码看起来清清爽爽
5. 循环依赖检测：能早期发现循环依赖问题，而不是等到运行时才报错

第三章：三者的华山论剑

让我们通过一个表格来直观对比三位选手：

第四章：实战演示

让我们来看一个完整的使用示例：

@Service
@RequiredArgsConstructor
@Slf4j // 这也是Lombok的好用功能，自动提供log对象
public class OrderService {
    private final OrderRepository orderRepo;
    private final PaymentService paymentService;
    private final NotificationService notificationService;
    
    public Order createOrder(Order order) {
        Order savedOrder = orderRepo.save(order);
        paymentService.processPayment(savedOrder);
        notificationService.sendOrderConfirmation(savedOrder);
        log.info("Order created successfully: {}", savedOrder.getId());
        return savedOrder;
    }
}

// 测试代码也变得异常简单
public class OrderServiceTest {
    @Test
    public void testCreateOrder() {
        // 直接通过构造器传入mock对象
        OrderRepository mockRepo = mock(OrderRepository.class);
        PaymentService mockPayment = mock(PaymentService.class);
        NotificationService mockNotification = mock(NotificationService.class);
        
        OrderService orderService = new OrderService(mockRepo, mockPayment, mockNotification);
        
        // 进行测试...
    }
}

第五章：一些注意事项

1. 确保Lombok已正确安装：在你的IDE和构建工具中配置好Lombok支持
2. 多个构造器时需要指定：如果一个类有多个构造器，需要用@Autowired标注Spring应该使用哪个
3. Optional依赖：如果需要Optional的依赖，可以使用@NonNull注解：

@RequiredArgsConstructor
public class ExampleService {
    private final @NonNull Optional<AdditionalService> additionalService;
}

结语：拥抱最佳实践

朋友们，时代在变，编程的最佳实践也在不断演进。从最早的XML配置，到注解注入，再到现在的构造器注入，我们一直在追求更优雅、更安全的代码编写方式。

final + @RequiredArgsConstructor不仅仅是一种技术选择，更是一种编程哲学的体现：明确依赖、不可变状态、易于测试。这些都是编写健壮、可维护代码的关键要素。

所以，下次当你需要注入依赖时，不妨试试这个组合拳，让你的代码变得更加坚固而优雅！

互动时间：大家在项目中更喜欢用哪种注入方式呢？欢迎在评论区分享你的经验和看法！