有时会使用@Value自动注入，但也有注入集合和数组等复杂类型的场景。 这是很容易写bug的场景。
1 @Value用于未注入期望值的字段或方法/构造函数的参数级别，指示包含注释元素的缺省表达式。
通常用于表达式驱动或属性驱动的依赖注入。 它还支持处理程序方法参数的动态分析
例如，在Spring MVC中，# { system properties.my prop } system properties.my prop # { system properties.my prop }样式的spel (system )
或者，也可以使用${my.app.myProp}样式属性中的占位符注入值。
3358www.Sina.com/实际处理由BeanPostProcessor执行。 这意味着不能在BeanPostProcessor或BeanFactoryPostProcessor类型中使用@Value。
V.S Autowired在组装对象成员的属性时，经常使用@Autowired进行组装。 但是，用@Value组装：
使用@Autowired通常不会设置属性值。 必须指定字符串值，因为定义中需要@Value。
通常，它常用于http://www.Sina.com/string类型的部件，因此被误认为不能用于非内置对象的部件。
可以通过以下方式注入属性成员：
@Value用于组装更多的字符串，支持多种强大的组装方法
application.properties具有以下属性：
user=adminpassword=pass然后在一个Bean中定义两个引用每个Bean的属性。
password返回了配置值，但用户是PC用户名，而不是配置文件中的指定值。
在问答中，@Value使用姿势没有问题，但user有正确的说明为什么不正确。
这需要熟悉Spring是如何基于@Value查询值的。
@Value的中心工作流defaultlIstablebeanfactory# doresolvedependency @ nullablepublicobjectdoresolvedependency (dependencydescriptor @ nullable string beanname， @ nullablesetstringautowiredbeannames，@ nullabletypeconvertertypeconverter ) throwsbeansexception type=descriptor.getdepepeted //@ value object value=getautowirecandidateresolver ().getsuggestedvalue(descriptor )； if(value！=null () if ) Valueinstanceofstring分析Value值string strval=resolveembeddedValue ) ) (string ) value )； beandefinitionBD=(beanname！=nullcontainsbean(beanname )？ getmergedbeandefinition (beanname ) : null； value=evaluatebeandefinitionstring (strval，bd )； (组件类型typeconverterconverter=(type converter！=null？ 类型转换器： gettype转换器()； try { return converter.convertifnecessary (value，type，descriptor.getTypeDescriptor ) }； } catch (unsupportedoperationexceptionex ) (}/.}http://www.Sina.com/的工作大致分为以下三个核心步骤：
1查找@value以确定此属性字段是否标记为@value :
qualifierannotationautowirecandidateresolver # findvaluevalueannotationtype位于@Value
如果分析字段将@Value的字符串值标记为@Value，则可以获得相应的字符串值并根据字符串值进行分析。 最终的分析结果可能是字符串or对象，具体取决于字符串的格式。
3如果获取在将分析结果转换为要装配的对象类型之前的步骤中生成的结果，则表明该结果可能与要装配的类型不匹配。
例如，如果定义了UUID，并且结果是字符串，则根据目标类型查找转换器以执行转换。
可分析的问题的关键是第二步骤，执行过程：
这里分析嵌入的值，替换占位符。 使用属性资源配置器根据属性源进行替换。
使用${user}获取替换值时，最终执行的搜索不仅仅是在application.property文件中。
可以看出，以下“来源”是置换的依据。
具体的检索执行是
属性资源管理器获取执行方式
Value字符串的分析是有顺序的，所有源都有CopyOnWriteArrayList，并且在启动时按顺序固定。 系统将按顺序逐个搜索“源”，并在找到任何源后立即返回。
通过查看systemEnvironment源，您可以看到它正好与user匹配，并且值不是admin。
所以，这真的是敌人的道路狭窄，正好在系统环境变量(systemEnvironment )中包含了相同名称的配置。 如果不考虑这些存在，将同名字符串设为@Value，就容易发生这样的问题。
修改时请不要使用相同的名称。 具体而言，修改如下。
user.name=adminuser.password=pass其实还是不行。
在名为systemProperties的PropertiesPropertySource源中正好存在user.name，这是偶然的。 因此，为了从根本上解决这个问题，不仅要注意避免环境变量，还要注意避免与系统变量等其他变量的冲突。
Spring为我们提供了许多易于使用的功能，但这些功能交织在一起可能会让我们误入一些漏洞。 只有了解它的工作原理，我们才能迅速识别和解决问题。