我们正常的开发时,对应不同的环境我们会有不同的配置文件:
java -Dspring.profiles.active={
环境} -jar ***.jar
为什么在application.yaml中配置会生效,而在另外三个不生效?
这就牵涉到,application.yaml的继承作用,也就是说无论是启动dev,test,prod,都会默认启动application.yaml配置.
如果启动dev环境,相当于启动了application-dev.yaml和application.yaml两个配置文件的并集,相同的属性,则以dev配置文件为主。相当于application-dev.yaml继承了application.yaml。
如果我们既要区分不同的环境,但是又要写在一个配置里面,就会需要这个属性。
如上图,我们在一个配置文件里配置了四个环境,中间是通过“—”分割成四个文档,YAML 文件可以由一或多个文档组成(也即相对独立的组织结构组成),文档间使用“—”(三个横线)在每文档开始作为分隔符。同时,文档也可以使用“…”(三个点号)作为结束符(可选)
这四种环境就是靠spring.profiles配置的。
没有配置 相当于 application.yaml 第一块
spring.profiles: dev 相当于 application-dev.yaml 第二块
spring.profiles: test 相当于 application-test.yaml 第三块
spring.profiles: prod 相当于 application-prod.yaml 第四块
而且 spring.profiles可以设定多个名称,中间通过逗号分割,如:
spring.profiles: dev,dev1
那么在激活时,
spring.profiles.active: dev
和
spring.profiles.active: dev1
都相当于激活这同一个配置,dev和dev1只是不同的别名罢了。
这个没什么好讲的,大家经常用,唯一要讲的是,可以同时激活多个配置文件,也是通过逗号分割,如:
spring.profiles.active: dev,test
dev和test两个配置里面,相同的属性的,谁写在后面谁优先级高。
比如,dev里面name: zhangsan test里面 name:lisi,那么name:lisi 生效。
不同的取并集。
首先 spring.profiles.include有spring.profiles.active一样的作用。可以激活对应的配置,其实spring.profiles.include的单纯作用就是将多个配置整合起来,
比如我有多个配置文件每个负责一部分配置,配置文件如下:
spring.profiles.include: prod_redis,prod_mq,prod_db
这样只需要激活prod就同时拥有了redis和mq,db的配置了
@profile注解一般是配合**@Bean**定义配置Bean,当对应的环境被激活时,会生成对应的配置bean。
// 当spring.profiles.active=dev时激活这个bean
@Profile("dev")
@Bean
public User devUser() {
return new User("dev", 20);
}
// 当spring.profiles.active=test时激活这个bean
@Profile("test")
@Bean
public User testUser() {
return new User("test", 21);
}