简单介绍：

在我们的开发过程中，我们的程序开发分为几个基本的阶段，比如开发阶段，调试阶段，运行阶段，在不同的阶段可能需要有不同的配置文件去对我们的项目做配置，那么要如何在不同的环境中配置不同的配置信息并使用，这就需要用到了多环境开发。

编写格式：我们以YAML格式的配置文件进行介绍

1、将多环境配置写在同一个配置文件中：

上图中展示的就是将多环境的配置，首先，多个环境之间使用”---“隔开，上面展示的环境有三个，其中最上面的环境一般为默认环境，默认环境中一般会配置一些公共属性，也就是所有的环境都会用到的属性。使用sprin.profiles属性指定环境的名字，这个环境的名字是环境的唯一标识，在我们启用环境的时候就是通过这个属性的属性值来找到我们要启用那一套环境。然后我们就可以在不同的环境中配置不同的配置项，在默认环境中，我们要通过spring.profiles.active属性指定要启用的环境的唯一标识，如果这个地方不指定，则默认启动默认环境。

根据上图可以看出来，我配置了三套环境，除了最上面的默认环境，还有两个我们自己配置的环境，分别是dav环境和pro环境，三套环境唯一的区别就是服务器的启动端口不同，所以我们在演示切换不同和环境配置的时候就可以根据端口来观察我们启动的是那一套环境。

首先，我们不在默认配置中启用任何的环境，也就是说当前我们启动的配置文件如下所示：

然后我们启动程序，服务器的端口应该是80端口，我们来观察是否正确：

 可以看到，我们的服务器确实在80端口启动了，然后我们切换环境到dav环境，切换环境的方法就是将spring.profiles.active的值修改成对应环境的唯一标识即可：

那么根据dav环境的配置，我们的服务器应该在82端口启动，我们观察服务器的启动端口即可确定我们的环境是否切换成功：

可以看到首先，我们的服务确实在82端口启动了，并且在上面还有一个地方，说明我们启用了一个名字叫做dav的环境配置，这样就说明我们的环境配置的切换就完成了。

2、将多环境配置写在多个配置文件中

之前我们介绍的都是将多个环境配置写在同一个配置文件中，但是当多个配置文件中的配置项开始变多，尤其是这些不同的环境的属性相同只不过是值不相同就和容易弄混，导致不好管理。那么我们就可以将不同的环境配置写在不同的配置文件中，一个文件就表示一个环境，这样就更方便我们的管理。

首先我们将我们之前写的两个环境拆分成不同的配置文件：

注意我这里的文件名：application-xxx.yml，这里需要着重说一下文件名，因为我们在配置文件中并没有标注环境的唯一标识，那么文件的后缀，也就是xxx的部分就是我们环境的唯一标识，当我们想要启动这个配置文件的时候，使用它来定位唯一的环境变量，比如我们要启动application-dav.xml这套环境，那么我们就需要将spring.profiles.active的值修改成dav：

 可以看到，确实是从我们在application-dav.yml中配置的端口启动了服务，并且上面也出现了使用dav环境的标识，现在我们再来换一下，启动 pro环境：

 这时候就变了， 变成我们在application-pro.yml中配置的端口启动了，那么就说明我们的配置是正确的。

3、在配置文件中引入其他的配置文件 

除了将不同环境的配置封装成单独的配置文件，那么有时候单个的环境配置中的配置项太多了，能不能也单独分出来进行更详细的区分呢？肯定是可以的，我们可以根据我们使用的技术将同一种技术的配置写在同一个配置中：

比如我们可以把跟Redis的相关技术的配置写在application-davRedis，这样就表示这是在dav环境下的Redis配置文件，就像是上图中我写入了三个配置，那么我们要如何引用呢？

我们在默认的配置文件中将我们之前写的多个分散的配置文件，通过include属性的方式引入进来，首先配置文件要放在同一个目录下，在写的时候，完整的文件名是application-davRedis.yml，我们可以简化成去掉application-，和后缀，也就是只写davRedis的形式。

并且在我们启动的时候，我们的配置文件的引用也会打印在日志上：

注意这里的配置文件的加载顺序，他和我们的书写顺序是有关系的， 我们书写的越靠后，在加载的时候也会靠后加载，最后一个是我们的环境配置。那么越靠后加载的配置文件，如果其中含有与前面的配置文件中冲突的部分，靠后的配置值会覆盖前面的配置值，当然我们的主环境配置文件时最后加载的，所以如果前面有与我们的主环境配置文件中冲突的配置项，最终都会被主环境配置中的的配置值覆盖掉。

4、新特性，使用group代替include

在之前我们将配置文件分成了主环境配置文件，以及其他的第三方技术配置文件。但是主环境配置文件和第三方技术配置文件的关联性不高，比如我们的第三方技术配置文件完全是根据文件名来区分他是在什么环境下使用的。并且如果我们要修改数据，除了要修改active的值，在下面引入的时候使用的include的值也要同时修改，就加大了我们的代码书写量。

那么有没有一个操作可以让我们把主环境配置文件和我们的第三方技术配置文件分个组，让我们在启动主环境配置文件的时候，自动将同一个环境配置下的其他第三方技术配置文件同时引入，肯定是有的。

在SpringBoot的2.4版本之后，我们可以使用group代替include来帮我们将要导入的配置文件进行分组：

可以看到，我们使用这个标签将dav属性和其同一环境下的所有的第三方技术的相关文件进行分组，当我们选择使用某一个环境之后，他会将主环境配置文件加载进来，并且将分组中对应环境的第三方技术配置文件同时加载进来。

那么在使用这种形式的时候，我们要注意，要保证你主环境配置文件的唯一标识，也就是application-dav.xml中的dav，与我们的分组中的分组名dav要保持一致，并且active的值也要是dav才能顺利的加载所有的配置文件：

只要保证这三个值都相等，那么对应的配置文件就会被顺利的导入，我们来看运行结果：

 注意这里的运行结果，我们会首先加载主配置文件，然后是剩下的第三方技术的配置文件，并且第三方配置文件的加载顺序与我们的书写顺序相关。这里就需要注意，第三方技术配置文件中的属性值不要覆盖掉我们的主环境配置文件中的属性值。

5、环境冲突 

除了SpringBoot中有环境这个概念，在Maven中其实也存在一个环境的概念，这是属于Maven的知识，我们并不展开说明，只是如果遇到我们在SpringBoot中配置环境没有生效的时候，考虑是否是因为SpringBoot的环境与Maven的环境配置冲突了，如果真是的是冲突了，那么此时我们的SpringBoot将沿用Maven的环境配置。

原因很简单，我们的SpringBoot导入依赖，配置默认值，这些所有的让我们开箱即用的配置和特性都是依赖Maven完成的，所以也就是说我们的SpringBoot是依赖Maven进行构建的，所以让配置发生冲突的时候肯定是沿用Maven的配置。

可以通过在Maven中使用compile配置环境让Maven和SpringBoot的环境统一解决环境冲突问题