似乎 ConditionalOnProperty 仅适用于类路径中的属性，如资源文件夹中的 application.properties。我需要一个最终用户可以通过外部属性打开和关闭的属性。一个例子非常简单：
配置类，读取外部属性。Sys.out 显示它正在正确读取文件。
@Configuration
@EnableAutoConfiguration
@PropertySource("file:/Users/end.user/MyApp/config/MyApp.properties")
public class PropertyConfigurer {
@Value("${featureOne}")
private String featureOne;
@PostConstruct
public void init() {
System.out.println("FeatureOne : " + featureOne);
}
}
要素类，如果通过 ConditionalOnProperty 启用该属性，则该组件类将被放入应用程序上下文中以便能够使用，否则永远不会实例化该组件。
@Component
@ConditionalOnProperty(name="featureOne", havingValue = "true")
public class FeatureOne {
@PostConstruct
public void init() {
System.out.println("Feature initialized");
}
}
正如您可以想象的那样，由于“featureOne”属性在构造此类之后才可用于 spring 上下文，因此我永远不会看到“功能已初始化”。如果有某种方法可以在类实例化时强制来自 @PropertySource 的属性可用于 spring 上下文。还是有其他方式？我也尝试过 @DependsOn 来自 FeatureOne 的 PropertyConfigurer，但有趣的是，这也不起作用。
TL; DR服务应该选择偶尔将数据保存在其本地数据库中，还是每次都向数据来源的服务请求数据？
让我们来看一个网上商店/订购应用程序的一般示例。服务A是用户会话管理服务。它处理用户正在做的事情，他可以做的事情等的业务逻辑。用户可以创建自己的衬衫来购买。服务B是一个数据聚合器，其中包含大量清单和可用资源。
用户开始创建衬衫，因此服务A向服务B发出请求，要求提供哪些样式/颜色。服务B向下发送可能选择的列表，然后服务A向用户显示。然后，用户选择一个，对其进行自定义，然后继续穿上新衬衫。再次，服务A必须向服务B请求什么样式/颜色可用。
现在，我们假设在用户会话的生命周期内，这些样式/颜色不会改变，并且我们知道这将是一次又一次地检索相同的数据。不只是这个用户，而是所有用户。因此，在这种情况下，由于样式/颜色确实是服务B领域的一部分，因此它们应该留在这里生活，或者建议防止所有这些不必要的调用，并应首次请求（临时）保存在服务A中会话生命周期中的数据，以防止使用即时通讯服务。
这是一个过于简化的示例，但问题仍然存在。设计该设计更建议采用哪种方法？例如，这通常适用于某些静态数据通过某些服务传递的情况，而该服务将在这些事务的生命周期中再次几次使用该数据。因此，我不确定该服务是否应该只是在生命周期内临时保存它，因为它知道数据在生命周期内不会发生变化就不会更改，也不会关心它，还是选择更多的即时通讯服务并每次都继续请求。