Spring Boot 模組化

工程 | Spring Boot 團隊 | 2025年10月28日 | ...

本週，我們繼續我們的通往 GA 系列，探索 Spring Boot 4 中的模組化工作。

Spring Boot 1.0 於 2014 年釋出時，它帶有一個單一的 spring-boot-autoconfigure jar，大小為 182 KiB。當然，最初的版本不支援太多功能，但多年來，這種情況已經改變。

Spring 的最大優勢之一是它支援大量技術，但每項新技術都會帶來成本。每次我們支援新功能時，自動配置 jar 都會增長。對於 Spring Boot 3.5，單個 spring-boot-autoconfigure jar 現在已達 2 MiB！

雖然磁碟空間很便宜，但大多數類實際上對您來說並不重要，因為它們針對的是您的應用程式中可能沒有的技術。這意味著您會得到大量關於不必要的類和配置屬性的自動完成建議。這增加了混亂和心智負擔，我們將在 Spring Boot 4 中改變這一點。

那麼，泡一杯舒緩身心的茶，和我們一起踏上這段旅程吧！

模組化的 Spring Boot 4

在 Spring Boot 4 中，我們將對自動配置的打包、交付和使用方式進行根本性改變。我們不再使用單一的、龐大的 spring-boot-autoconfigure jar，而是將功能拆分為更小、更集中的模組。

這一變化是出於可維護性、清晰度和更精簡的執行時佔用空間。它對包結構、啟動器以及終端使用者如何從 Spring Boot 3 遷移到 Spring Boot 4 產生連鎖反應。Spring Boot 支援的每項技術現在都有自己的啟動器，其中一些是 Spring Boot 4 中新增的。

為什麼要模組化程式碼庫？

現在，您可能會問自己：為什麼要這樣做？為什麼要觸及程式碼庫中的幾乎所有內容並將其拆分？事實上，這是一項極具挑戰性的工作，我們甚至在 Spring Boot 3.5 釋出之前就開始了。然而，它的好處卻非常引人注目。

可維護性和架構清晰度：透過更小的模組和強制的邊界，團隊和我們的貢獻者可以更清晰地理解每個領域。模組邊界成為契約而不是軟約定。您的 IDE 也提供了更專注的視角。不再有您永遠不需要的類的程式碼完成建議，只有您實際使用的配置屬性會出現在 IDE 彈出視窗中。

減小 artifact 大小和佔用空間：您的應用程式不再需要引入包含許多您可能不使用的功能的大型 autoconfigure jar，而是隻引入相關的模組。這減少了類路徑開銷、啟動掃描成本和磁碟空間。

更強的訊號和避免意外的自動配置：由於模組是受作用域限制的，Spring Boot 對您引入依賴項的原因有了更強的訊號。您是為了伺服器端 @Controller 支援而包含了 spring-webflux jar，還是因為您想使用 WebClient？透過專注於模組，我們實際上知道了。您將永遠不需要呼叫 SpringApplication.setWebApplicationType(WebApplicationType.NONE)，因為如果您只通過新的 spring-boot-webclient 模組使用 WebClient，類路徑上甚至不會有任何 Web 伺服器自動配置。

啟用新的用例：我們已經看到模組化開闢了新的用例，我們認為未來還會有更多。例如，您現在可以獨立於 Actuator 使用 Micrometer 指標。您可以只引入釋出指標的模組，而無需完整的 Actuator 依賴鏈，這在 Spring Boot 3 中很難實現。

測試支援

事實證明，spring-boot-autoconfigure 並不是唯一需要模組化的 jar。雖然沒有那麼大，但 spring-boot-test-autoconfigure jar 也需要拆分。例如，@AutoConfigureDataJdbc 註解用於測試 Spring Data JDBC，因此它應該與 spring-boot-data-jdbc 模組對齊。

我們不希望將測試支援程式碼放在模組本身中，因此我們建立了測試專用的模組。對於上面的示例，該註解已移至 spring-boot-data-jdbc-test jar。

為了保持簡單，我們還確保每個常規啟動器都提供了一個測試啟動器 POM。例如，如果您的應用程式依賴於 spring-boot-starter-webmvc，那麼它也應該在 test 作用域中依賴 spring-boot-starter-webmvc-test。

如何遷移到 Spring Boot 4

將應用程式從 Spring Boot 3 遷移到 4 所需的工作量將因多種因素而異。對於大多數應用程式，我們希望這個過程只是對 pom.xml 或 build.gradle 檔案進行一些更新，以及一些包匯入修復。

以下是大多數應用程式應遵循的流程：

1. 精簡您的主要啟動器依賴項

所有現有的啟動器現在都傳遞性地引入了其相關模組。這意味著如果您已經在使用啟動器，您的應用程式將擁有它所需的大部分模組。您可能需要做的一件事是為以前沒有啟動器的技術新增啟動器。這是一個典型的 Spring Boot 3 Web 應用程式 Maven POM：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
  <groupId>org.flywaydb</groupId>
  <artifactId>flyway-core</artifactId>
</dependency>

在 Spring Boot 3 中，當 Flyway jar 存在時，Flyway 會自動配置。在 Spring Boot 4 中，您現在需要包含 Flyway 啟動器以確保您擁有 spring-boot-flyway 模組。我們還藉此機會重新命名了一些啟動器，使它們更具一致性。在這裡，web 啟動器現在被命名為 webmvc。

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webmvc</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-flyway</artifactId>
</dependency>

您可以在遷移指南中找到每種技術的啟動器列表。

2. 使用新的測試啟動器

您使用的每個主要啟動器都有一個相應的測試啟動器，您也需要新增它。這樣做可以確保您獲得正確的測試支援。請確保將測試啟動器新增到 test 作用域。對於我們上面的示例應用程式，我們將使用以下測試啟動器：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-webmvc-test</artifactId>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security-test</artifactId>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-flyway-test</artifactId>
  <scope>test</scope>
</dependency>

這將包含您測試 Web 元件、控制器、模擬 MVC、安全性和 Flyway 所需的一切。

3. 調整手動或自定義配置

如果您的專案或任何自定義啟動器以前依賴於 spring-boot-autoconfigure 或手動引入了自動配置類，您將需要將這些匯入/依賴項替換為新的模組化等效項。

如果您引用 Spring Boot 的包，您還需要更新包名。由於模組現在以 org.springframework.boot.<module> 開頭，因此自動配置支援類的匯入可能需要更改。這也適用於自定義器，例如。

4. 審查自定義啟動器和共享庫

如果您的組織維護自定義 Spring Boot 啟動器或共享依賴項，您應該根據模組化重新評估它們。由於包名和模組的重構，我們強烈不建議在同一 artifact 中同時支援 Spring Boot 3 和 4。

經典模組

為了簡化過渡，Spring Boot 4 保留了經典啟動器 POM。這些“經典啟動器”捆綁了所有（模組化）自動配置模組，但不包含它們的傳遞依賴項。實際上，如果您在升級時遇到問題，經典啟動器可以作為有用的工具。您可以採用經典啟動器來“啟動並執行”，修復任何包匯入，然後隨著時間的推移，遷移到更具選擇性的模組依賴項。要使用經典啟動器，您的依賴項將如下所示：

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-classic</artifactId>
</dependency>
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test-classic</artifactId>
  <scope>test</scope>
</dependency>

結論

Spring Boot 4 對自動配置的模組化是朝著更易於維護、可組合和精簡的框架邁出的有意識的架構步驟。透過將功能拆分為專注的模組，引入經典啟動器並提供測試啟動器，Spring Boot 為您提供了增量升級路徑的工具。儘管存在一些遷移開銷（特別是對於自定義或深度耦合的程式碼），但其在清晰度、佔用空間和執行時行為方面的好處使其成為一項值得的投資。

如果您正在計劃遷移，請嘗試只使用您需要的模組來建立更輕量、更富有表現力的應用程式。如果您需要更多時間來完成遷移，請使用經典啟動器，並在您的日程安排允許時採用模組化。

一如既往，我們歡迎您提出任何反饋。如果您發現錯誤，請在我們的 GitHub 問題跟蹤器上報告。感謝所有一直關注里程碑和釋出候選版本並已經這樣做的朋友。

Spring 部落格