我可能会完全更改解决方案：直接注入系统属性，而不是注入引用系统属性的属性
例如
@Value("#{ systemProperties['JAVA_MY_ENV'] }") private String myVar;要么
<property name ="myVar" value="#{systemProperties['JAVA_MY_ENV']}"/>我使用这样的属性占位符配置器
<bean id="propertyConfigurer" > <property name="locations"> <list> <value>classpath:someprops.properties</value> </list> </property> <property name="ignoreResourceNotFound" value="true" /> <property name="searchSystemEnvironment" value="true" /> <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
您还必须记住使用以下命令将参数传递给程序
-DJAVA_MY_ENV=xyz
这样，当您运行生产版本时，您可以通过一件事，而在运行测试时，您可以通过另一件事。
同样，我经常做的事情是这样的：
<property name="locations"> <list> <value>classpath:someprops.properties</value> <value>classpath:someprops-{environment}.properties</value> </list> </property>环境是prod / stage / test / int / ci /
local（每个环境1个-您现在可能只有2个或3个）。您可以将环境变量传递给程序。无论其在本地PC
/测试上的生产/运行情况如何，任何应相同的属性都应位于someprops.properties属性文件中。特定于环境/运行方式的任何内容都将放在更特定的文件中（除非覆盖机制，否则应将其放置在someprops.properties文件以及默认文件中）
例如在classpath：someprops.properties中
url=www.mysite.com
在classpath：someprops-local.properties中
url=localhost
通过使用此基本思想，您可以以干净的方式将测试和程序的正常运行属性分开。
