使用Spring开发时，我们通常有两种依赖注入的方式，基于注解@Autowired的依赖注入和基于构造函数的依赖注入。
用IDEA开发过程中，如果使用@Autowired注入，通常会有如下警告
Inspection info: Spring Team recommends: "Always use constructor based dependency injection in your beans. Always use assertions for mandatory dependencies".
翻译成中文：
spring 团队建议：“在bean中始终使用基于构造函数的依赖注入，始终使用断言来强制依赖”。
为什么spring团队会这样建议呢？
可能会出现空指针异常
首先我们看一个使用@Autowired注入的简单例子：
public class Car {
@Autowired
private Wheel wheel;
public void run() {
wheel.roll();
}
}
假设测试代码如下，就会发生空指针异常：
Car car = new Car();
car.run();// -> NullPointerException
出现这种问题的关键在于，Car允许创建无状态的对象，也就是说在构建Car时允许Wheel为空。
下面我们使用构造注入的方式：
public class Car {
private final Wheel wheel;
public Car(Wheel wheel) {
Assert.notNull(wheel,"Wheel must not be null");
this.wheel = wheel;
}
public void run() {
wheel.roll();
}
}
这样我们就有如下优点：
- 在创建Car对象的时候，强制依赖Wheel对象，确保创建Car对象时每个对象都是有效状态。
- 构造器中可以添加对象初始化的校验逻辑
- 可以清楚的区分对象是通过setter方法注入的（非final对象）还是通过强制依赖注入的（final对象）
构造注入代码变得臃肿？
或许有的读者可能会说，构造注入的话，如果依赖的对象很多，构造器参数就会很多，显得代码很臃肿。这种情况的话，就要考虑这个类是符合足单一职责原则了，将这个类拆分为多个类。
而且使用@Autowired的自动装配会让依赖对象变得很容易，随着项目的迭代，自动注入的对象可能会变得很多，但是使用构造注入，构造器就会变得很臃肿，提醒你代码里有bad smell了，需要拆分或重构代码了。
还有一个问题是@Autowired注入的对象无法使用final关键字，因为final对象必须在构造器中初始化。
@Autowired测试不友好
使用注解的自动装配，我们的业务代码确实会变得比较少，但是单元测试该如何写呢？
Wheel wheel = Mock(Wheel);
Car car = new Car();
//通过反射来将wheel对象注入到Car对象里
car.run();
通过反射注入到Car对象里，我们的单元测试代码就会显得很繁琐，或者在Car对象里提供一个Wheel的setter方法？这样代码不是很优雅。
如果是构造注入，单元测试就会变成如下：
Wheel wheel = Mock(Wheel);
Car car = new Car(wheel);
car.run();
单元测试代码就会变得很优雅，而且在后续的开发中，如果Car对象添加了强制依赖的Tank对象，单元测试也不会出现没有设置的强制依赖项。
Spring 的DI设计模式，是将依赖关系的创建和类本身分离，将依赖关系创建的职责交给了类注入器做，允许程序设计的松耦合，并遵循单一职责原则和依赖反转原则。因此使用@Autowired自动装配的字段在Spring容器之外无法使用（不包含通过反射设置对象的方式）。
构造注入可以在受影响的类中轻松表明对象的依赖关系，但是@Autowired的自动装配其实对外隐藏了这些依赖关系，需要到对应的类中查看代码才能明确依赖。
使用Lombok来解决构造注入样板代码的问题
Lombok是一个强大的java样板代码解决方案，这里来介绍下使用Lombok简化构造注入的代码：
@RequiredArgsConstructor
public class Car {
private final @NonNull Wheel wheel;
public void run() {
wheel.roll();
}
}
@RequiredArgsConstructor注解会在编译过程中，将所有的final对象作为参数添加到构造器中。
小结
下面我们来总结下注解注入和构造注入的优缺点：
注解注入
++ 写更少的代码
-- 代码变得不安全
-- 单元测试会比较复杂
-- 无法使用fianl对象
-- 违反单一职责原则变得很容易
-- 对受影响的类隐藏自己的依赖关系
构造注入
++ 更安全的代码
++ 测试友好
++ 依赖添加代价较高，显式的表明代码的bad smell
++ 在受影响的类中显式的表明依赖关系
-- 需要写更多的业务代码（可以通过Lombok解决）
