• 在我们通过IDEA编写Spring的代码的时候，假如我们编写了如下代码：

  

• IDEA会给我们一个warning警告：

  

• 翻阅官方文档；我们会发现：

  

• 大意就是强制依赖使用构造器注入，可选依赖使用setter注入
• 那么这是为什么呢？使用字段注入又会导致什么问题呢？
• 单一职责问题
• 我们都知道，根据SOLID设计原则来讲，一个类的设计应该符合单一职责原则，就是一个类只能做一件功能，当我们使用基于字段注入的时候，随着业务的暴增，字段越来越多，我们是很难发现我们已经默默中违背了单一职责原则的
• 但是如果我们使用基于构造器注入的方式，因为构造器注入的写法比较臃肿，所以它就在间接提醒我们，违背了单一职责原则，该做重构了

  

  

• 可能产生NPE
• 对于一个bean来说，它的初始化顺序为：
• 静态变量或静态语句块 -> 实例变量或初始化语句块 -> 构造方法 -> @Autowired
• 所以，在静态语句块，初始化语句块，构造方法中使用Autowired表明的字段，都会引起NPE问题

  

• 相反，用构造器的DI，就会实例化对象在使用的过程中，字段一定不为空
• 隐藏依赖
• 对于一个正常的使用依赖注入的Bean来说，它应该“显式”的通知容器，自己需要哪些Bean，可以通过构造器通知，public的setter方法通知，这些设计都是没问题的
• 但是对于private的filed来说，从设计的角度来讲，外部的容器是不应该感知到bean内部的private内容的，所以理论上，private的filed是没办法通知到容器的（不考虑反射，单从设计角度理解），所以从这个角度来看，我们不能通过字段注入
• 不利于测试
• 很明显，使用了Autowired注解，说明这个类依赖了Spring容器，这让我们在进行UT的时候必须要启动一个Spring容器才可以测试这个类，显然太麻烦，这种测试方式非常重，对于大型项目来说，往往启动一个容器就要好几分钟，这样非常耽误时间
• 不过，如果使用构造器的依赖注入就不会有这种问题，或者，我们可以使用Resource注解也可以解决上述问题
• Spring支持哪些注入方式
• 1. 字段注入

  

• 2. 构造器注入

  

• 3. setter注入

  

• 使用构造器注入可能有哪些问题
• 如果我们两个bean循环依赖的话，构造器注入就会抛出异常：

  

  

• 如果两个类彼此循环引用，那说明代码的设计一定是有问题的
• 如果临时解决不了，我们可以在某一个构造器中加入@Lazy 注解，让一个类延迟初始化即可