最常见的配置绑定的场景，是在自定义的bean中通过@Value注解将某个属性和对应的配置绑定：

application.yml

某个bean

在创建定时任务的bean时，使用的@Scheduled注解也可以通过相同的方式绑定配置，本质上和上面是相同的。

@ConfigurationProperties提供了更强大的功能，比如在我们需要批量绑定的时候，可以将多个配置项一起绑定到某个bean的多个属性上，而不用每一个属性都使用一个@Value注解：

这种定义，暗示着应用中存在下面的配置：

这样，四个属性就可以一次性绑定到一个spring bean上。

上面的示例，都有一个共同的特点：在自定义的bean中绑定配置。更直白一点，作为spring bean的代码是项目内的代码，不是第三方引入的依赖。

其中一个特征，就是我们直接在类上使用诸如@Component、@Service、@RestController的注解来声明为spring的bean。

如果是引入的第三方依赖，要实例化为spring的bean，需要我们自己进行配置。在当前项目环境中，这种类一般很少，直接写配置类就可以了：

只要这个配置类能被@SpringBootApplication或@ComponentScan扫描到，对应的bean就会被创建。

顺便提一下，如果我们在配置bean的时候，需要注入其他的bean依赖，可以将依赖作为参数。spring会根据类型和参数名来寻找对应的bean，然后作为参数参入进来：

一个新的问题：当我们需要为第三方依赖的bean绑定配置的时候，应该如何做。

基于已有的知识，我们可以将配置项先绑定到自己的代码，然后再调用第三方依赖的setter方法，将对应的配置一一设置到bean中：

对应的配置大概下面的样子：

@ConfigurationProperties简化了这个工作，我们可以将它和@Bean一起使用，这种绑定的工作就会被自动完成：

spring会在someType()执行完之后，按照默认的绑定策略将配置绑定到返回的bean中。其效果和上文中我们逐个将配置绑定到bean中是一样的。

需要注意的是，spring按照setter的规范去绑定变量，配置的key和bean的setter方法要相呼应。比如某个bean有属性jdbcUrl，但对应的setter方法是setUrl，那么配置文件中应该配置的是url而不是jdbc-url。

如果setter方法在bean对应的类型的父类中，绑定同样有效。

我们可能会有不同的场景：允许用户选择使用哪一个数据源的实现，比如druid或者hikari。我们需要根据用户选择的数据源类型，来配置DataSource的实例化和参数绑定的动作。

换句话来说，上文中someType()方法可能返回的具体类型有多种，而使用@ConfigurationProperties的前提是我知道返回的具体是哪一种，以根据其setter方法设计对应的配置。所以我们所说的上述场景，就无法直接使用了。

如果我们退一步，依然可以通过显示的逐个绑定来完成这项工作。首先，我们将所有的数据源类型的相关参数，都一一绑定到我们自己的类里面，然后在构造数据源Bean的时候，根据用户配置的类型来构建具体的数据源Bean，并将对应的配置参数通过setter方法进行设置。代码大意大概如下：

你可能注意到druid和hikari的配置有些不同，这是与具体的实现类及其父类所提供的setter方法相关的。

上面的代码应该可以自己想得到，它只是组合了我们已知的知识。

但是在我们接触了自动绑定之后，再手动逐个绑定看起来有点蠢。接下来介绍另一种更加可控的自动绑定方式，帮助我们消除那些无聊的代码。

依然是基于同样的配置，我们可以这样编写配置类：