@
vate32 Autowired 注入在多人大型项目里，我碰到过一些问题，因为团队成员的理解不一样：容易造成滥用（可能是为了复用某个能力，就注入一堆 bean ）、循环依赖（底层模型注入了高层模型的 bean，可能交叉）、多模块的项目很难管理（有种拔出萝卜带出泥的感觉，因为 A 和 B 项目共享了模块 C，B 项目在 C 模块增加了一个 Autowired 注入，A 项目没有感知）。
我自己认为，构造器注入更好，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 的设计问题了。