我想知道其他人在使用Spring Boot 2.0.3时是否注意到了这个问题。在我的application.properties中，将spring.profiles.active设置为将要使用的全局配置文件。然后，根据所部署的环境，在环境变量中设置spring.profiles.include。但是，在应用程序运行时，它只会选择包含属性指定的配置文件。所以
application.properties
spring.profiles.active=http
环境
spring.profiles.include=dev
结果
2018-08-09 13：45：35.025信息[main]应用程序：下列配置文件处于活动状态：dev
代替
2018-08-09 13：45：35.025信息[main]应用程序：下列配置文件处于活动状态：dev，http
如果两个属性（spring.profiles.active和spring.profiles.include）都设置在同一位置，则可以正常工作。对我来说这似乎是个错误，还是我在做一些愚蠢的事情？
据我了解，Spring将遍历每个属性的来源，直到找到该属性为止-在这里似乎没有发生这种情况。
答案 0 :(得分：1)
TL; DR ：不要使用spring.profiles.active：这与您认为的不完全一样。
长版
Uuum，我尝试调试一下如何在spring-boot中加载配置文件：
为了模仿您的情况，我放了一个
spring.profiles.include=dev在我的环境 spring.profiles.active=demo
我到达了ConfigFileApplicationListener$Loader，那就是魔术发生的地方：
在initializeActiveProfiles()期间，加载程序在我的环境中寻找spring.profiles.active（因为环境优先于属性），然后寻找spring.profiles.include（仍在环境中） ）。然后，它激活了找到的配置文件，在我的情况下为dev。
然后，它尝试从其propertySources加载后续配置文件，在该文件中确实找到了spring.profiles.active=dem ...
但，在maybeActivateProfiles()中，发生this.activatedProfiles设置为true（duh，dev已被激活），因此{{ 1}}是自愿未激活的。
我对此的看法是，{strong}仅使用demo（作为开关）来激活第一个配置文件，然后只有spring.profiles.active适用。有趣的是，include的优先级高于include。
答案 1 :(得分：1)
嗯，也许这不是最好的解决方案，但是您可以枚举环境变量中的所有配置文件：
spring.profiles.active=http, dev