我对直接字段依赖注入很感兴趣。传统上，Spring支持构造函数注入（向构造函数提供参数）和基于setter的注入（在调用时调用setter）。
然而，Spring也能够进行直接字段注入（设置对象的成员字段而不使用setter方法），这可以通过使用@Autowired注释字段来证明。自动装配仅限于“bean”，因此不能注入原始值（尽管可以通过创建类为“java.lang.String”的bean来绕过这个问题 - 这可以工作，但具有自动装配的普通警告）。除此之外，Spring还支持@Value从属性等直接将值设置到成员字段中。
然而，Spring不允许属性直接设置为成员字段（而不进行自动装配）。
我的问题是：为什么？
显然它有能力这样做，那为什么没有呢？是否存在任何严重的负面影响阻止了这样做？或者说这种能力受到限制，因此只有自动装配才有意义？需要比调用setter更大的hack吗？
请注意，我不希望讨论一般情况下是否应该拥有setter和getter，只是想了解Spring做出这个选择的原因。
@Autowired注解使用反射使私有字段可被访问 (详见这个相关问题)。我可以看到三个原因，为什么它不在Spring配置文件中使用：
我认为我已经找到了答案。我查看了Spring源代码，看到了这些特性的实际实现方式。以下是我的发现：
通过XML设置属性可能是Spring中最早的部分，它非常依赖于“java.beans”类来进行内省、属性枚举等操作。显然，这些类根本不支持字段内省。在此基础上还有类型转换机制，用于确定如何将属性值转换为适合相应属性的值。这里没有明确可分离的部分。
所有的@Autowired等内容都是在BeanPostProcessor中实现的，该处理器具有自己的类型匹配机制，与类型转换无关。这也是为什么它只注入bean。@Value也基本上是一样的，它只是在那里解决了问题，并且与属性没有任何关系。
因此，为属性添加字段注入支持并不是一个简单的工程努力，因为执行其中之一的代码部分与另一个几乎完全分开。
这并不能完全回答“为什么”，但我认为这比我听到的其他解释更令人信服，说明了为什么Spring没有添加直接的字段依赖注入。除非他们对此有根本性的反对意见（我怀疑，因为他们想允许对现有第三方类进行配置，而不仅仅是JavaBeans），否则，这只是一项工程努力的问题，以获得该功能。
它通过JSR-250 @Resource注释（在Spring 3.0+中）支持此功能。
个人而言，我更喜欢这种方式而不是setter注入，并且在考虑构造函数注入时对此有复杂的感觉。以下是我考虑过的问题：
1）构造函数注入是自我记录bean依赖项的好方法（优点），但会创建很多DRY违规：（a）私有字段，（b）构造函数参数，（c）构造函数代码以从参数设置字段，（d）bean配置中的附加代码（无论是在@Configuration类中还是在xml中）。为了一些封装纯度而产生了大量DRY违规，我甚至不关心。这几乎不是封装的违规 - 但它确实在某种程度上依赖于某些遵守JSR-250注释的注入容器（见下文）。
2) 创建了对JSR-250兼容容器的依赖。我对此有复杂的感受。当我第一次听说@Resource时，我认为它会使我的系统更难测试，于是我将其抛之脑后。然而，最终我还是在我的测试中使用了Spring。我仍然可以像往常一样使用模拟bean，所以这从来不是一个问题。问题在于，在测试之外，你真正想要重用它的时候是什么时候呢？在我看来，如果你正在设计系统以利用容器，则应该拥抱它并使用它。追求灵活性是否值得违反DRY原则，不在容器内运行？至少使用JSR-250注释，您可以在任何JEE6环境中运行并获得所需的注入。
3) 如果在容器之外实例化一个对象，则可能会创建一些不太好的调试场景：例如，您将获得空指针异常而不是友好的提示。这是一种权衡。我个人认为这并不可怕——我的意思是，如果您在带有@Resource的行上获得NPE，那么您很快就会意识到它没有被注入。
