@sheng3233386 直接使用名称的吗，但是这个能够避免上面说的空指针错误吗，好像跟直接使用 autowired 是一样的。
@chendy 写着着实很爽，但是担心有的地方不让用 Lombok （似乎想多了）
@gdtdpt 多谢大佬指点，还是得看实际情况来。从 ApplicationContext 获取到 Bean 的方法还没用到过，去学习一下。
constructor 注入需要你先有一个 constructor， 所以手写一个也好 lombok 生成一个也好，还是 IDEA command+N generate 一个也好，都是不错的选择。
我 jio 得循环依赖才是无法使用 constructor 注入的罪魁祸首，毕竟即使你的 constructor 需要的参数再多，也就是一个注解或者一个快捷键自动生成的事。由于设计上的失误导致的循环依赖会使你压根用不了构造器注入，而且有循环依赖的项目多多少少会有其他的 badsmell …（破窗。。。
我自己认为，构造器注入更好，Spring 官方也推荐，构造器注入在一定程度上：强迫开发者去思考，当前的 bean 为什么要注入其他的依赖。
如果你用了 Lombok 自动实现了构造器注入，那么这种强迫开发者去思考的动机就没有了，还不如直接 Autowired 。
手动的用构造器注入（除了某些特定的类，例如 Controller 之类的），我认为有如下优点：
1.强迫我自己思考：这个注入是否是必须的，是否可以用工具类？用设计模式？或者其他的优雅方法来实现这个逻辑设计。
2.注入的改变是可感知的。在大型多模块架构的协作工程里，可能很有用。大家在协作里复用了模块 C，一旦你在模块里增加了注入参数，那么其他人用到了模块 C 注入 bean，会立刻编译错误。
3.因为大型工程里，一般会把某个模块作为一个 jar 包，让其他应用引用，Configuration 里动态声明 Bean 的时候，感觉更从容。因为我知道当前的 bean 所有的依赖都是构造方式注入，我可以从容选择一组自己指定的 bean 进去组装。
4.某种意义上，实现了业务代码和 Spring 框架的解耦。因为构造器注入的话，就像在写普通的 java 的 pojo 。我们不需要 @Autowired 不需要 @Service 和 @Component，业务类里基本不会 import spring 的东西，依赖 Configuration 的动态装配能力，从构造注入声明了一个个的 bean，完全可控（适合有洁癖的人）。如果有场景，需要移植的话，会很容易，例如：从 Spring 框架移植到 google 的 guice 框架。
那么，如果构造器注入的 bean 很多的时候，也是一个强迫性的提醒:是实时思考当前的 bean 的设计问题了。