现在我们已经知道，我们可以通过在运行jar时提供一系列的参数来定制SpingBoot为我们默认做好的设置。如果我们要定制的属性很多，在实际开发中，你可能会需要覆盖上百个SpringBoot的默认设置，如果这些设置写在java -jar 运行命令中一点都不优雅，也不利于维护。那如何是好？
SpringBoot提供了专门的属性配置文件和配置接口。
SpringBoot默认加载的属性配置文件名称为application，就像你用Spring框架一样，也有一个全局的配置文件。
你可以在resource目录下创建application.properties，把需要定制的SpringBoot属性写入其中，
比如你要修改SpringBoot启动的默认端口，就加入server.port属性；要修改redis的默认端口，可以加入spring.redis属性；要修改rabbitmq的连接地址，可以加入spring.rabbitmq.host属性，就像这样：
重启项目后，就看到默认端口已经修改为8081。这跟使用启动命令java -jar运行道理是一样的，只不过看起来更利于维护。如果你觉得就这么几个参数，直接写在启动命令中岂不更省事？实际项目中需要进行设置的内容往往很多，甚至还要复杂。
因此，自己定义application.properties来管理框架定制属性的意义就很重要了。
而且，application.properties的作用远不止于此。
他还能方便区分和管理不同环境的配置。开发人员经常要在本地环境、测试环境甚至生产环境中切换，以便更好的开发或排查问题。在以前，我们可能是通过在application.properties中注释掉一部分并写上另一部分内容的方式来切换不同环境。然而，现在有更优雅的方式。
可以通过再application后添加不同的后缀名称来区分不同项目环境，不用全部杂糅在一个配置文件中。比如这样：
一般约定，dev代表开发环境，test代表测试环境， prod代表生产环境。通过不同的后缀名称，不同环境配置一目了然。
最后在根配置文件，也就是application.properties中添加 spring.profiles.active=dev来指定启用哪个配置，比如这里的dev就对应application-dev.properties，也就是我们约定的开发环境配置。
那如果application.properties中和application-dev.properties都有相同的配置属性，结果如何呢？
答案是，spring.profiles.active对应了哪个就是哪个生效，除非那个配置文件中没有定义的属性，才会被application.properties中定义的覆盖，如果两个文件中都没有，则沿用springboot默认设置。
另外，附带提一下，springboot配置文件还有一种yaml格式，比如上述的application.properties可以命名为application.yml，作用完全相同，只不过yaml文件是用树形结构来编写属性，就像这样：
而当项目中同时存在application.properties和application.yml时，起作用的是application.properties。 同一目录下，properties配置优先级 高于 YAML配置优先级。
**使用建议**
1、尽量统一使用一种格式的配置文件，尽量不要两种格式混用。
2、properties虽然传统而且好用，但官方更推荐用yaml格式，因为树形结构可读性更强，这也是很多编程语言的趋势。
（yaml的编写语法和规范，后续会继续谈到）
3、一般情况下，我们都会放在resource根目录下，也可以放在resource/config目录下，这种情况下，优先级最高的是resource/config中的配置文件，这也是官方推荐的方式。因此，建议大家将springboot本身的配置文件放在resource/config目录下。
最后，附上完整的配置参数清单，需要修改默认的哪些设置，对照这个清单上找到，然后application文件中覆盖默认属性接口。springboot的这些属性很多是要另外在pom中添加相关的starter才能使用这些功能和参数定制。
定制参数列表：
https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html