【注解使用】使用@Autowired后提示：Field injection is not recommended（Spring团队不推荐使用Field注入）

 问题发生场景：

在使用 IDEA 开发 SpringBoot 项目时，在 Controller 类中使用注解 @Autowired 注入一个依赖出现了警告提示，查看其他使用该注解的地方同样出现了警告提示。这是怎么回事？由于先去使用了SpringBoot并没有对Spring进行系统性学习，所以做一个记录。

Field injection is not recommended（不再推荐使用字段注入） 

因为功力有限，所以以下内容均来自别人的博客：

Field injection is not recommended（Spring团队不推荐使用Field注入）_编程火箭车的博客-CSDN博客

为什么不推荐使用Field注入

• 违反单一责任原则

添加新的依赖项非常容易。添加6个、10个甚至12个依赖项没有问题。当使用构造函数注入时，在某一点之后，构造函数参数的数量会变得过高，并且很明显会出现问题。依赖太多通常意味着类有太多的责任。这可能违反了单一职责原则和关注点分离，这表明类需要进一步的检查和重构。当直接注入字段时，没有这样的警告，因为这种方法可以无限扩展。

• 依赖隐藏

使用依赖注入容器意味着类不再负责管理自己的依赖项。获取依赖项的职责是从类中提取的。由其他人现在负责提供依赖项——依赖注入容器或在测试中手动分配它们。当类不再负责获取其依赖项时，它应该使用公共接口（方法或构造函数）清楚地与它们通信。这样就可以清楚类需要什么，以及它是可选的（Setter）还是强制的（构造函数）。

• 依赖注入容器耦合

DI 框架的核心思想之一是托管类不应该依赖于所使用的 DI 容器。换句话说，它应该只是一个普通的 POJO，可以独立地实例化它，前提是将所有必需的依赖项传递给它。通过这种方式，可以在单元测试中实例化它，而不需要启动 DI 容器，并单独测试它（使用的容器更像是集成测试）。如果没有容器耦合，则可以将该类作为托管或非托管类使用，甚至可以切换到新的 DI 框架。

然而，当直接注入字段时，无法直接用所有需要的依赖项实例化类。这意味着:

• 有一种方法（通过调用默认构造函数）可以在一个状态中使用 new 关键字来创建一个对象，该状态中缺少一些强制协作者，使用将导致 NullPointerException。
• 这样的类不能在 DI 容器（测试、其他模块）之外重用，因为除了反射之外，没有其他方法为它提供所需的依赖项。

• 不变性

与构造函数不同，Field 注入不能用于将依赖项分配给最终字段。

那Spring团队推荐什么注入方式呢？

推荐构造器注入

官方文档里的说法：Core Technologies

Constructor-based or setter-based DI?

Since you can mix constructor-based and setter-based DI, it is a good rule of thumb to use constructors for mandatory dependencies and setter methods or configuration methods for optional dependencies. Note that use of the @Required annotation on a setter method can be used to make the property a required dependency.

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state. As a side note, a large number of constructor arguments is a bad code smell, implying that the class likely has too many responsibilities and should be refactored to better address proper separation of concerns.

Setter injection should primarily only be used for optional dependencies that can be assigned reasonable default values within the class. Otherwise, not-null checks must be performed everywhere the code uses the dependency. One benefit of setter injection is that setter methods make objects of that class amenable to reconfiguration or re-injection later. Management through JMX MBeans is therefore a compelling use case for setter injection.

Use the DI style that makes the most sense for a particular class. Sometimes, when dealing with third-party classes for which you do not have the source, the choice is made for you. For example, if a third-party class does not expose any setter methods, then constructor injection may be the only available form of DI.

 最终要的是这句：

以下解释来自：https://www.cnblogs.com/joemsu/p/7688307.html#_caption_2

The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.

​ 咳咳，再来简单的翻译一下：这个构造器注入的方式啊，能够保证注入的组件不可变，并且确保需要的依赖不为空。此外，构造器注入的依赖总是能够在返回客户端（组件）代码的时候保证完全初始化的状态。
 

下面来简单的解释一下：

• 依赖不可变：其实说的就是final关键字
• 依赖不为空（省去了我们对其检查）：当要实例化FooController的时候，由于自己实现了有参数的构造函数，所以不会调用默认构造函数，那么就需要Spring容器传入所需要的参数，所以就两种情况：1、有该类型的参数->传入，OK 。2：无该类型的参数->报错。所以保证不会为空，Spring总不至于传一个null进去吧
• 完全初始化的状态：这个可以跟上面的依赖不为空结合起来，向构造器传参之前，要确保注入的内容不为空，那么肯定要调用依赖组件的构造方法完成实例化。而在Java类加载实例化的过程中，构造方法是最后一步（之前如果有父类先初始化父类，然后自己的成员变量，最后才是构造方法，这里不详细展开。）。所以返回来的都是初始化之后的状态。

结论

应尽量避免 Field 注入。推荐使用构造函数或方法来注入依赖项。两者各有利弊，其用法取决于具体情况。但是，由于这些方法可以混合使用，所以这不是非必须选择一种，可以将 Setter 和构造函数注入合并到一个类中。构造函数更适合于强制依赖项和以不变性为目标的情况。对于可选的依赖项，Setter 更好。

然后我在另一篇博客中也读到，使用@Resource替代@Autowired就没有这个提示了.....