為什么 SpringBoot 寧可挨罵也要干掉 Spring.factories？
兄弟們，今天咱們來聊一個 SpringBoot 社區里的 “勁爆” 話題 —— 為什么 SpringBoot 寧可被罵也要干掉 spring.factories？這個問題就像一顆投入平靜湖面的石子，在開發者圈里掀起了不小的波瀾。很多老司機可能會問：“spring.factories 用得好好的，干嘛要改？” 別急，咱們今天就來扒一扒這背后的 “恩怨情仇”。
一、spring.factories 的前世今生
（一）曾經的 “功臣”
在 SpringBoot 的早期版本中，spring.factories 可是個 “大紅人”。它就像一個神奇的 “配置管家”，允許第三方庫通過 META-INF/spring.factories 文件注冊自動配置類。比如說，你引入一個數據庫驅動的依賴，它就能自動幫你配置好數據源，是不是很方便？
那它是怎么工作的呢？簡單來說，SpringBoot 啟動的時候，會掃描所有 JAR 包中的 META-INF/spring.factories 文件，然后根據里面的配置加載對應的自動配置類。這種 “約定優于配置” 的方式，大大減少了開發者的工作量，讓我們可以快速搭建應用。
（二）暗藏的 “隱患”
但是，隨著時間的推移，spring.factories 的問題也逐漸暴露出來。就像一個看似完美的人，身上卻隱藏著一些致命的缺點。
- 啟動速度的 “噩夢”
想象一下，當你的項目依賴了成百上千個 JAR 包時，SpringBoot 就像一個勤勞的 “掃街工”，要一個一個地掃描每個 JAR 包中的 spring.factories 文件。這得多慢啊！實測顯示，某電商平臺在依賴 300+ 個 JAR 包的情況下，僅配置加載階段就消耗了 2.3 秒啟動時間。這對于追求高性能的現代應用來說，簡直是一場 “噩夢”。
- 維護的 “災難現場”
當項目越來越大，模塊越來越多時，spring.factories 文件就像一個 “大雜燴”，里面的內容越來越多，維護起來簡直就是一場 “災難”。不同的模塊可能會引入沖突的配置，讓開發者們頭疼不已。
- 模塊化的 “絆腳石”
隨著 Java 9 引入模塊系統（JPMS），spring.factories 的問題就更明顯了。它基于類路徑掃描的方式，與模塊化設計理念格格不入，無法很好地支持 Java 模塊系統。
二、SpringBoot 的 “忍無可忍”
（一）性能的 “生死時速”
在這個 “速度為王” 的時代，SpringBoot 團隊顯然也意識到了啟動速度的重要性。為了提升性能，他們決定對 spring.factories 下手。畢竟，誰也不想自己的應用啟動得像 “蝸牛爬” 一樣慢。
（二）模塊化的 “大勢所趨”
Java 模塊系統的出現，標志著 Java 生態向模塊化發展的趨勢。SpringBoot 作為 Java 生態的重要一員，自然不能落后。而 spring.factories 這種基于類路徑掃描的方式，顯然已經跟不上時代的步伐了。
（三）GraalVM 的 “臨門一腳”
近年來，GraalVM 原生鏡像技術越來越火。它可以將 Java 應用編譯成原生可執行文件，大大提升性能和啟動速度。但是，spring.factories 基于運行時類路徑掃描的機制，與 GraalVM 的提前編譯（AOT）模型存在根本性沖突。為了更好地支持 GraalVM，SpringBoot 必須做出改變。
三、新貴登場：AutoConfiguration.imports
（一）“新管家” 的閃亮登場
為了解決 spring.factories 的問題，SpringBoot 3.0 引入了一個新的配置文件 ——META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports。這個文件就像一個 “新管家”，取代了 spring.factories 的位置。
它的使用方式非常簡單，只需要在文件中列出需要自動配置的類的全限定名，每行一個。例如：
com.example.MyAutoConfiguration
com.example.AnotherAutoConfiguration這種方式不僅提高了配置的可讀性和可維護性，還支持模塊化管理。不同的模塊可以有自己的 AutoConfiguration.imports 文件，獨立維護自己的自動配置列表。
（二）性能的 “質的飛躍”
新的配置方式在性能上有了顯著提升。首先，它減少了不必要的類掃描，因為每個擴展點類型使用單獨的文件，避免了加載不需要的配置。其次，它與 Java 模塊系統兼容，不再是模塊化的 “絆腳石”。實測數據顯示，使用新方案后，類加載時間減少了 30%，類加載量減少了 29%。
（三）功能的 “全面升級”
除了性能提升，新方案在功能上也有了全面升級。它支持條件化配置，開發者可以使用 @Conditional 注解來動態決定是否加載某個配置類。例如：
@AutoConfiguration
@ConditionalOnClass(name = "com.example.ExternalService")
public class MyAutoConfiguration {
// 配置類的內容
}這樣，只有當類路徑下存在 ExternalService 類時，這個配置類才會生效。這種靈活的配置方式，讓開發者可以更好地控制應用的行為。
四、社區的 “愛恨情仇”
（一）開發者的 “吐槽大會”
任何重大的變更都會引起社區的討論，這次也不例外。一些習慣了 spring.factories 的開發者開始 “吐槽”：“為什么要改？我用得好好的！”“遷移成本太高了，我不想改！” 甚至有人在社交媒體上發起了 “抗議”。
（二）Spring 團隊的 “良苦用心”
面對社區的質疑，Spring 團隊也給出了自己的解釋。他們表示，雖然這次變更會給一些開發者帶來不便，但從長遠來看，這是為了提升 SpringBoot 的整體性能和可維護性。他們希望通過這次變更，讓 SpringBoot 更好地適應現代 Java 生態的發展，為開發者提供更高效、更靈活的配置方式。
（三）遷移的 “最佳實踐”
為了幫助開發者順利遷移，Spring 團隊提供了詳細的遷移指南。首先，開發者需要識別 spring.factories 中的配置，然后將其轉換為 AutoConfiguration.imports 文件。例如，將 spring.factories 中的：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.MyAutoConfiguration,\
com.example.AnotherAutoConfiguration轉換為 AutoConfiguration.imports 文件中的：
com.example.MyAutoConfiguration
com.example.AnotherAutoConfiguration此外，開發者還可以使用 spring-boot-autoconfigure-processor 工具來優化自動配置加載，減少手動管理的負擔。
五、實戰案例：從 spring.factories 到 AutoConfiguration.imports
（一）創建自定義自動配置
假設我們要創建一個自定義的自動配置類 MyAutoConfiguration，它需要根據配置文件中的屬性來決定是否生效。我們可以按照以下步驟進行：
- 創建配置屬性類
@ConfigurationProperties(prefix = "myapp")
public class MyProperties {
private boolean enabled = true;
private String name = "default";
// getter 和 setter 方法
}- 創建自動配置類
@AutoConfiguration
@EnableConfigurationProperties(MyProperties.class)
@ConditionalOnProperty(prefix = "myapp", name = "enabled", havingValue = "true", matchIfMissing = true)
public class MyAutoConfiguration {
private final MyProperties properties;
public MyAutoConfiguration(MyProperties properties) {
this.properties = properties;
}
@Bean
@ConditionalOnMissingBean
public MyService myService() {
return new MyServiceImpl(properties.getName());
}
}- 注冊自動配置
在 META-INF/spring/ 目錄下創建 org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，并添加以下內容：
com.example.MyAutoConfiguration（二）遷移已有的配置
如果你的項目中已經使用了 spring.factories，遷移到新方案也很簡單。首先，找出 META-INF/spring.factories 中的 EnableAutoConfiguration 配置項，然后將其中的自動配置類列表遷移到 AutoConfiguration.imports 文件中。例如，將：
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
com.example.MyAutoConfiguration,\
com.example.AnotherAutoConfiguration遷移為：
com.example.MyAutoConfiguration com.example.AnotherAutoConfiguration最后，檢查項目是否依賴了 spring-boot-autoconfigure-processor，并進行優化。
六、總結：擁抱變化，走向未來
SpringBoot 干掉 spring.factories 的決定，雖然在短期內引起了一些爭議，但從長遠來看，這是一次必要的 “革命”。新的配置方式不僅提升了性能，還增強了靈活性和可維護性，更好地適應了現代 Java 生態的發展。
對于開發者來說，雖然遷移過程可能會遇到一些困難，但這也是一個學習和成長的機會。我們應該擁抱變化，積極學習新的配置方式，讓自己的技術棧跟上時代的步伐。畢竟，在技術的世界里，停滯不前就意味著落后。
