Spring依赖注入：为什么官方建议慎用@Autowired

很多初学者在接触Spring时，对@Autowired注解情有独钟。这个注解能轻松实现依赖注入，节省了大量代码。但是随着项目变得复杂，@Autowired可能会引发一些问题。因此，官方在某些文档和社区交流中提到：不建议盲目使用@Autowired，而是更推荐构造函数注入。本文将讨论官方为何建议慎用@Autowired，并提供相关的代码例子。

1. 容易导致隐式依赖

许多开发者喜欢直接使用@Autowired注解：

@Service
public class MyService {
    @Autowired
    private MyRepository myRepository;
}

这种写法看起来简单，但问题在于类的依赖关系被隐藏得太深。这段代码中，MyService和MyRepository的关系是一种“隐形依赖”，完全依赖@Autowired来注入。如果有同事接手这段代码，他们可能无法理解myRepository是什么，只能通过IDE或运行时才能推断出来。隐式依赖会导致代码看似简单，但维护起来却很费力。添加新的依赖或更改依赖顺序可能会让人感到困惑。

为了解决这个问题，可以使用构造函数注入代替：

@Service
public class MyService {
    private final MyRepository myRepository;

    // 构造函数注入，依赖一目了然
    public MyService(MyRepository myRepository) {
        this.myRepository = myRepository;
    }
}

这样做的好处是依赖关系清晰可见，更易于测试。构造函数注入可以手动传入mock对象，方便编写单元测试。

2. 会导致强耦合

许多开发者喜欢直接使用@Autowired注入具体实现类，比如：

@Service
public class MyService {
    @Autowired
    private SpecificRepository specificRepository;
}

表面上看起来没问题，但实际上这样会使MyService和SpecificRepository之间产生强耦合。如果有一天业务需要切换成另一个实现类，比如AnotherSpecificRepository，就需要修改代码、修改注解，同时也需要修改相关的测试。

为了解耦，可以使用接口和构造函数注入：

@Service
public class MyService {
    private final Repository repository;

    public MyService(Repository repository) {
        this.repository = repository;
    }
}

然后通过Spring的配置文件或@Configuration类配置具体实现：

@Configuration
public class RepositoryConfig {
    @Bean
    public Repository repository() {
        return new SpecificRepository();
    }
}

这种做法的好处是可以灵活切换实现类而不需要修改核心逻辑代码，同时符合面向接口编程的思想，降低了耦合性，提高了可扩展性。

3. 容易导致NullPointerException

一些开发者喜欢以下方式编写代码：

@Service
public class MyService {
    @Autowired
    private MyRepository myRepository;

    public void doSomething() {
        myRepository.save(); // 可能引发NullPointerException
    }
}

问题出在哪里？如果Spring容器还没有来得及注入依赖，代码就会运行（例如在构造函数或初始化方法中直接调用依赖），结果自然就是NullPointerException。

使用构造函数注入可以彻底避免null的可能性：

@Service
public class MyService {
    private final MyRepository myRepository;

    public MyService(MyRepository myRepository) {
        this.myRepository = myRepository; // 确保依赖在对象初始化时就已注入
    }

    public void doSomething() {
        myRepository.save();
    }
}

构造函数注入的另一个优点是依赖注入是强制的，Spring容器不给你注入就会报错，让问题尽早暴露。

4. 自动装配容易搞出迷惑行为

Spring的自动装配机制有时候表现得像“黑魔法”，特别是当项目中存在多个候选Bean时。比如：

@Service
public class MyService {
    @Autowired
    private Repository repository; // 容器中有两个Repository实现类，怎么办？
}

如果存在两个实现类，如SpecificRepository和AnotherRepository，Spring容器会直接报错。解决方法有两种：

• 指定@Primary。
• 使用@Qualifier手动指定。

但这些方式会让代码变得更加复杂，可能会导致一些问题。

为了解决这个问题，可以使用构造函数注入+显式配置：

@Configuration
public class RepositoryConfig {
    @Bean
    public Repository repository() {
        return new SpecificRepository();
    }
}

直接告诉Spring应该使用哪个实现类，避免让容器自行猜测，从而避免以后“配错药”的情况。

5. 写单元测试非常痛苦

最后，讨论一下测试问题。

@Autowired依赖于Spring容器的工作，但在编写单元测试时，大家通常不想依赖Spring容器（麻烦、慢）。结果就是：

• 字段注入：无法手动传入mock对象。
• 自动装配：有时不清楚使用的Bean是哪个，导致测试困难。

为了解决这个问题，构造函数注入天生就是为单元测试设计的：

public class MyServiceTest {
    @Test
    public void testDoSomething() {
        MyRepository mockRepository = mock(MyRepository.class);
        MyService myService = new MyService(mockRepository);

        // 测试逻辑
    }
}

可以直接传入mock对象，测试简单、优雅。

总结

简单总结下问题：

1. 隐式依赖降低了代码可读性。
2. 强耦合违背了面向接口编程的思想。
3. 字段注入容易引发NullPointerException。
4. 自动装配存在一些问题。
5. 编写单元测试困难。

那到底怎么办？使用构造函数注入，清晰、稳健、测试友好，官方推荐不是没有道理的。

但是，@Autowired并不是不能使用，只是需要根据具体场景来选择。在开发中，养成使用构造函数注入的习惯，能够使你的代码更加健壮，减少潜在问题，提高工作效率！

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。