在上一篇文章的結尾處我們簡單的說了一下PropertiesConfigurationFactory中的bindPropertiesToTarget這個方法的内容，在這個方法中有這樣的一段代碼：
首先先看一下我們在這個地方進行debug所看到的現象：
這裡的names是SpringBoot根據我們在ConfigurationProperties中設定的prefix的值和屬性的值所能相容的配置項的key，這裡一共有98種key存在。
上圖中的是我們在ConfigurationProperties中設定的prefix所能比對到的值的情況。我們進入到getPropertySourcesPropertyValues這個方法中看一下這個方法的内容：
1)處的代碼如下： 這裡主要做的是擷取配置項key的比對器
2)處的代碼是我們要分析的一個重點，我們進入到PropertySourcesPropertyValues這個類的構造方法中看一下:
這裡給出一個propertySources的debug截圖資訊：
注意看黑框中的内容，看看黑框中的順序你會有什麼發現呢？在上面的代碼中我們可以發現，這裡會循環propertySources中的PropertySource來進行處理。
processPropertySource的内容如下：
我們直接進入到processEnumerablePropertySource中看一下：
如果你從上面看到現在的話，那麼在這裡是不是會有一個疑問呢？因為這裡是循環propertySources來擷取配置項的值的，如果這樣的話，那麼後面的propertySources中的值豈不是會覆寫前面的propertySources中的值嗎？但是我們看到的現象卻又不是這樣的，這又是怎麼一回事呢？秘密就在getEnumerableProperty中。
是以到這裡我們可以看明白為什麼優先級高的配置項會最終生效的原因。以上代碼簡化之後就是這樣的：
在processEnumerablePropertySource中還有一個這樣的方法：
真正的屬性值的設定的動作是在org.springframework.boot.bind.PropertiesConfigurationFactory#doBindPropertiesToTarget這個方法中的這句話中完成的：