如果有看过各类@Enable注解，就一定会看到，每一个@Enable几乎都会被@Import所注解，而一般使用@Enable时，都会和@SpringBootApplication写一起，这个写法的一方面是比较清晰，集中写到一起，还有个原因就是部分@Enable在定义时，没有使用@Configuration来进行注解，需要借助于一个能被Spring容器启动时处理的配置类上。
上面的这段代码分析，正好解释了@Enable背后的实现原理。
总结其实总的看下来，@Configuration就是一个标志注解，更大的作用就是为别的注解服务的。这么说有点矛盾，主要是觉得本身不具备什么功能性。
至于其能实现的对字段进行配置值绑定来说，可以使用@ConfigurationProperties或者@Value这两个注解来实现，由此可见，@Configuration并不是用于将配置文件的配置值，绑定到配置类的，这个工作和他没有任何关系，对于一些配置文件的配置来说，可以使用@Component注解来对普通的配置类注解，达到一样的效果，而并非一定要使用@Configuration(@Configuration注解派生自@Component)。
通过我们上面的分析，被@Configuration注解的类，仅有存在以上那几个注解时，才有意义，才能被ConfigurationClassPostProcessor所处理，而这个处理过程中，和配置值绑定一毛钱的关系都没有。
实际上配置值的绑定，都是在Bean实例化后，Bean属性填充期间进行的。
@ConfigurationProperties注解会在ConfigurationPropertiesBindingPostProcessor执行时进行处理，这个处理器是一个BeanPostProcessor。
@Value注解的处理是在AutowiredAnnotationBeanPostProcessor这个BeanPostProcessor中来处理的，这个处理器同时也是处理@Inject、 @Autowired、 @Resource的BeanPostProcesoor。
Spring或者SpringBoot中，大量的使用各种后置处理器，除了对主体框架(Bean的生命周期)的理解外，剩下的主要就是熟悉这些支持各种功能的PostProcessor。
还有个值得注意的是，@Configuration有个方法proxyBeanMethods，这个方法返回true时，默认也是true，会对我们的配置类，生成一个代理类，注意，这里是直接生成一个代理类，并且最后实例化时，也是使用这个代理类进行实例化Bean，这个就给我们一个启发，如果想对一些无法直接修改又被Spring容器所管理的的Bean，是否可以通过自定义BeanDefinitionRegistryProcessor的方式，来对原Class做一个增强，从而实现我们的目的。
PS：是否具备切实可行性，并不保证，只是觉得如果遇到，可以尝试下。