配置基础
Spring Boot的默认配置文件位置为： src/main/resources/application.properties。
关于Spring Boot应用的配置内容都可以集中在该文件中了，根据我们引入的不同Starter模块，可以在这里定义诸如：容器端口名、数据库链接信息、日志级别等各种配置信息。比如，我们需要自定义web模块的服务端口号，可以在application.properties中添加server.port=8888来指定服务端口为8888。
Spring Boot的配置文件除了可以使用传统的properties文件之外，还支持现在被广泛推荐使用的YAML文件。
YAML采用的配置格式不像properties的配置那样以单纯的键值对形式来表示，而是以类似大纲的缩进形式来表示。比如：下面的一段YAML配置信息
environments:
dev:
url: http://dev.bar.com
name: Developer Setup
prod:
url: http://foo.bar.com
name: My Cool App
与其等价的properties配置如下。
environments.dev.url=http://dev.bar.com
environments.dev.name=Developer Setup
environments.prod.url=http://foo.bar.com
environments.prod.name=My Cool App
通过YAML的配置方式，我们可以看到配置信息利用阶梯化缩进的方式，其结构显得更为清晰易读，同时配置内容的字符量也得到显著的减少。除此之外，YAML还可以在一个单个文件中通过使用spring.profiles属性来定义多个不同的环境配置。例如下面的内容，在指定为test环境时，server.port将使用8882端口；而在prod环境，server.port将使用8883端口；如果没有指定环境，server.port将使用8881端口。
server:
port: 8881
---
spring:
profiles: test
server:
port: 8882
---
spring:
profiles: prod
server:
port: 8883
注意：YAML目前还有一些不足，它无法通过@PropertySource注解来加载配置。但是，YAML加载属性到内存中保存的时候是有序的，所以当配置文件中的信息需要具备顺序含义时，YAML的配置方式比起properties配置文件更有优势。
自定义参数
我们除了可以在Spring Boot的配置文件中设置各个Starter模块中预定义的配置属性，也可以在配置文件中定义一些我们需要的自定义属性。比如在application.properties中添加：
book.name=SpringCloudInAction
book.author=ZhaiYongchao
然后，在应用中我们可以通过@Value注解来加载这些自定义的参数，比如：
@Component
public class Book {
@Value("${book.name}")
private String name;
@Value("${book.author}")
private String author;
// 省略getter和setter
}
@Value注解加载属性值的时候可以支持两种表达式来进行配置：
- 一种是我们上面介绍的PlaceHolder方式，格式为
${...}，大括号内为PlaceHolder - 另外还可以使用SpEL表达式（Spring Expression Language）， 格式为
#{...}，大括号内为SpEL表达式
参数引用
在application.properties中的各个参数之间，我们也可以直接通过使用PlaceHolder的方式来进行引用，就像下面的设置：
book.name=SpringCloud
book.author=ZhaiYongchao
book.desc=${book.author} is writing《${book.name}》
book.desc参数引用了上文中定义的book.name和book.author属性，最后该属性的值就是ZhaiYongchao is writing《SpringCloud》。
使用随机数
在一些特殊情况下，有些参数我们希望它每次加载的时候不是一个固定的值，比如：密钥、服务端口等。在Spring Boot的属性配置文件中，我们可以通过使用${random}配置来产生随机的int值、long值或者string字符串，这样我们就可以容易的通过配置来属性的随机生成，而不是在程序中通过编码来实现这些逻辑。
${random}的配置方式主要有一下几种，读者可作为参考使用。
# 随机字符串
com.didispace.blog.value=${random.value}
# 随机int
com.didispace.blog.number=${random.int}
# 随机long
com.didispace.blog.bignumber=${random.long}
# 10以内的随机数
com.didispace.blog.test1=${random.int(10)}
# 10-20的随机数
com.didispace.blog.test2=${random.int[10,20]}
该配置方式可以用于设置应用端口等场景，避免在本地调试时出现端口冲突的麻烦.
命令行参数
在命令行方式启动Spring Boot应用时，连续的两个减号--就是对application.properties中的属性值进行赋值的标识。所以，java -jar xxx.jar --server.port=8888命令，等价于我们在application.properties中添加属性server.port=8888。
通过命令行来修改属性值是Spring Boot非常重要的一个特性，通过此特性，理论上已经使得我们应用的属性在启动前是可变的，所以其中端口号也好、数据库连接也好，都是可以在应用启动时发生改变，而不同于以往的Spring应用通过Maven的Profile在编译器进行不同环境的构建。其最大的区别就是，Spring Boot的这种方式，可以让应用程序的打包内容，贯穿开发、测试以及线上部署，而Maven不同Profile的方案每个环境所构建的包，其内容本质上是不同的。但是，如果每个参数都需要通过命令行来指定，这显然也不是一个好的方案，所以下面我们看看如果在Spring Boot中实现多环境的配置。
多环境配置
我们在开发任何应用的时候，通常同一套程序会被应用和安装到几个不同的环境，比如：开发、测试、生产等。其中每个环境的数据库地址、服务器端口等等配置都会不同，如果在为不同环境打包时都要频繁修改配置文件的话，那必将是个非常繁琐且容易发生错误的事。
对于多环境的配置，各种项目构建工具或是框架的基本思路是一致的，通过配置多份不同环境的配置文件，再通过打包命令指定需要打包的内容之后进行区分打包，Spring Boot也不例外，或者说更加简单。
在Spring Boot中多环境配置文件名需要满足application-{profile}.properties的格式，其中{profile}对应你的环境标识，比如：
application-dev.properties：开发环境application-test.properties：测试环境application-prod.properties：生产环境
至于哪个具体的配置文件会被加载，需要在application.properties文件中通过spring.profiles.active属性来设置，其值对应配置文件中的{profile}值。如：spring.profiles.active=test就会加载application-test.properties配置文件内容。
下面，以不同环境配置不同的服务端口为例，进行样例实验。
-
针对各环境新建不同的配置文件
application-dev.properties、application-test.properties、application-prod.properties -
在这三个文件均都设置不同的
server.port属性，如：dev环境设置为1111，test环境设置为2222，prod环境设置为3333 -
application.properties中设置
spring.profiles.active=dev，就是说默认以dev环境设置 - 测试不同配置的加载
- 执行
java -jar xxx.jar，可以观察到服务端口被设置为1111，也就是默认的开发环境（dev） - 执行
java -jar xxx.jar --spring.profiles.active=test，可以观察到服务端口被设置为2222，也就是测试环境的配置（test） -
执行
java -jar xxx.jar --spring.profiles.active=prod，可以观察到服务端口被设置为3333，也就是生产环境的配置（prod）
按照上面的实验，可以如下总结多环境的配置思路：
application.properties中配置通用内容，并设置spring.profiles.active=dev，以开发环境为默认配置application-{profile}.properties中配置各个环境不同的内容- 通过命令行方式去激活不同环境的配置
加载顺序
在上面的例子中，我们将Spring Boot应用需要的配置内容都放在了项目工程中，虽然我们已经能够通过spring.profiles.active或是通过Maven来实现多环境的支持。但是，当我们的团队逐渐壮大，分工越来越细致之后，往往我们不需要让开发人员知道测试或是生成环境的细节，而是希望由每个环境各自的负责人（QA或是运维）来集中维护这些信息。那么如果还是以这样的方式存储配置内容，对于不同环境配置的修改就不得不去获取工程内容来修改这些配置内容，当应用非常多的时候就变得非常不方便。同时，配置内容都对开发人员可见，本身这也是一种安全隐患。对此，现在出现了很多将配置内容外部化的框架和工具，后续将要介绍的Spring Cloud Config就是其中之一，为了后续能更好的理解Spring Cloud Config的加载机制，我们需要对Spring Boot对数据文件的加载机制有一定的了解。
Spring Boot为了能够更合理的重写各属性的值，使用了下面这种较为特别的属性加载顺序：
- 命令行中传入的参数。
SPRING_APPLICATION_JSON中的属性。SPRING_APPLICATION_JSON是以JSON格式配置在系统环境变量中的内容。java:comp/env中的JNDI属性。- Java的系统属性，可以通过
System.getProperties()获得的内容。 - 操作系统的环境变量
- 通过
random.*配置的随机属性 - 位于当前应用jar包之外，针对不同
{profile}环境的配置文件内容，例如：application-{profile}.properties或是YAML定义的配置文件 - 位于当前应用jar包之内，针对不同
{profile}环境的配置文件内容，例如：application-{profile}.properties或是YAML定义的配置文件 - 位于当前应用jar包之外的
application.properties和YAML配置内容 - 位于当前应用jar包之内的
application.properties和YAML配置内容 - 在
@Configuration注解修改的类中，通过@PropertySource注解定义的属性 - 应用默认属性，使用
SpringApplication.setDefaultProperties定义的内容
优先级按上面的顺序有高到低，数字越小优先级越高。
可以看到，其中第7项和第9项都是从应用jar包之外读取配置文件，所以，实现外部化配置的原理就是从此切入，为其指定外部配置文件的加载位置来取代jar包之内的配置内容。通过这样的实现，我们的工程在配置中就变的非常干净，我们只需要在本地放置开发需要的配置即可，而其他环境的配置就可以不用关心，由其对应环境的负责人去维护即可。
2.x 新特性
在Spring Boot 2.0中推出了Relaxed Binding 2.0，对原有的属性绑定功能做了非常多的改进以帮助我们更容易的在Spring应用中加载和读取配置信息。下面本文就来说说Spring Boot 2.0中对配置的改进。
配置文件绑定
简单类型
在Spring Boot 2.0中对配置属性加载的时候会除了像1.x版本时候那样移除特殊字符外，还会将配置均以全小写的方式进行匹配和加载。所以，下面的4种配置方式都是等价的：
- properties格式：
spring.jpa.databaseplatform=mysql
spring.jpa.database-platform=mysql
spring.jpa.databasePlatform=mysql
spring.JPA.database_platform=mysql
- yaml格式：
spring:
jpa:
databaseplatform: mysql
database-platform: mysql
databasePlatform: mysql
database_platform: mysql
Tips：推荐使用全小写配合-分隔符的方式来配置，比如：spring.jpa.database-platform=mysql
List类型
在properties文件中使用[]来定位列表类型，比如：
spring.my-example.url[0]=http://example.com
spring.my-example.url[1]=http://spring.io
也支持使用逗号分割的配置方式，上面与下面的配置是等价的：
spring.my-example.url=http://example.com,http://spring.io
而在yaml文件中使用可以使用如下配置：
spring:
my-example:
url:
- http://example.com
- http://spring.io
也支持逗号分割的方式：
spring:
my-example:
url: http://example.com, http://spring.io
注意：在Spring Boot 2.0中对于List类型的配置必须是连续的，不然会抛出UnboundConfigurationPropertiesException异常，所以如下配置是不允许的：
foo[0]=a
foo[2]=b
在Spring Boot 1.x中上述配置是可以的，foo[1]由于没有配置，它的值会是null
Map类型
Map类型在properties和yaml中的标准配置方式如下：
- properties格式：
spring.my-example.foo=bar
spring.my-example.hello=world
- yaml格式：
spring:
my-example:
foo: bar
hello: world
注意：如果Map类型的key包含非字母数字和-的字符，需要用[]括起来，比如：
spring:
my-example:
'[foo.baz]': bar
全新的绑定API
在Spring Boot 2.0中增加了新的绑定API来帮助我们更容易的获取配置信息。下面举个例子来帮助大家更容易的理解：
例子一：简单类型
假设在propertes配置中有这样一个配置：com.didispace.foo=bar
我们为它创建对应的配置类：
@Data
@ConfigurationProperties(prefix = "com.didispace")
public class FooProperties {
private String foo;
}
接下来，通过最新的Binder就可以这样来拿配置信息了：
@SpringBootApplication
public class Application {
public static void main(String[] args) {
ApplicationContext context = SpringApplication.run(Application.class, args);
Binder binder = Binder.get(context.getEnvironment());
// 绑定简单配置
FooProperties foo = binder.bind("com.didispace", Bindable.of(FooProperties.class)).get();
System.out.println(foo.getFoo());
}
}
例子二：List类型
如果配置内容是List类型呢？比如：
com.didispace.post[0]=Why Spring Boot
com.didispace.post[1]=Why Spring Cloud
com.didispace.posts[0].title=Why Spring Boot
com.didispace.posts[0].content=It is perfect!
com.didispace.posts[1].title=Why Spring Cloud
com.didispace.posts[1].content=It is perfect too!
要获取这些配置依然很简单，可以这样实现：
ApplicationContext context = SpringApplication.run(Application.class, args);
Binder binder = Binder.get(context.getEnvironment());
// 绑定List配置
List<String> post = binder.bind("com.didispace.post", Bindable.listOf(String.class)).get();
System.out.println(post);
List<PostInfo> posts = binder.bind("com.didispace.posts", Bindable.listOf(PostInfo.class)).get();
System.out.println(posts);