SpringBoot多模块配置与构建教程

“纵有疾风来，人生不言弃”，这句话送给正在学习文章的朋友们，也希望在阅读本文《Spring Boot多模块配置与构建详解》后，能够真的帮助到大家。我也会在后续的文章中，陆续更新文章相关的技术文章，有好的建议欢迎大家在评论留言，非常感谢！

构建Spring Boot多模块项目的核心在于通过模块化提升项目的可维护性和依赖管理效率。1. 首先创建一个父项目，类型为pom，负责统一管理依赖版本、插件配置及子模块聚合；2. 父项目通过dependencyManagement定义依赖版本，避免各子模块重复声明；3. 每个子模块在其pom.xml中声明父项目，并专注于自身业务逻辑，可引用其他子模块或公共依赖；4. 构建时在父项目根目录执行mvn clean install，Maven会自动处理模块顺序和依赖关系。多模块结构有助于实现模块解耦、统一依赖、提升团队协作效率和构建灵活性，同时需注意避免循环依赖、合理管理配置文件、优化构建速度等实践问题。

Spring Boot多模块项目，说白了，就是把一个大系统拆分成多个相互关联又相对独立的子项目来管理和构建。这玩意儿的核心价值在于它能帮你更好地组织代码、统一管理依赖、提高构建效率，尤其是在大型项目或者微服务架构的演进过程中，简直是必备技能。配置得当，能让你的开发体验和项目维护变得顺畅很多。

解决方案

要构建Spring Boot多模块项目，首先得有一个父项目来统领全局，它通常不包含实际的业务代码，主要负责聚合子模块和统一管理依赖版本。

父项目 pom.xml 示例：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example.mymulti</groupId>
    <artifactId>my-multi-parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging> <!-- 关键：父项目必须是pom类型 -->

    <name>my-multi-parent</name>
    <description>Parent project for Spring Boot multi-module application</description>

    <!-- 统一管理Spring Boot版本，子模块无需再声明 -->
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.2.5</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>

    <properties>
        <java.version>17</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <!-- 可以定义其他常用库的版本号 -->
        <lombok.version>1.18.30</lombok.version>
    </properties>

    <modules>
        <!-- 在这里列出所有的子模块 -->
        <module>my-service-core</module>
        <module>my-service-api</module>
        <module>my-service-web</module>
        <!-- 还可以有更多，比如 my-service-common, my-service-dao 等 -->
    </modules>

    <dependencyManagement>
        <!-- 统一管理依赖版本，子模块引用时无需指定version -->
        <dependencies>
            <dependency>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>${lombok.version}</version>
                <scope>provided</scope>
            </dependency>
            <!-- 其他常用的、希望统一版本的依赖 -->
        </dependencies>
    </dependencyManagement>

    <build>
        <pluginManagement>
            <!-- 统一管理插件版本和配置 -->
            <plugins>
                <plugin>
                    <groupId>org.springframework.boot</groupId>
                    <artifactId>spring-boot-maven-plugin</artifactId>
                    <version>${spring-boot.version}</version> <!-- 注意，这里的版本来自parent -->
                    <executions>
                        <execution>
                            <goals>
                                <goal>repackage</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>

子模块 pom.xml 示例（以 my-service-web 为例）：

每个子模块都需要声明它的父项目，这样它就能继承父项目的依赖管理、插件管理以及其他属性。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <!-- 声明父项目 -->
    <parent>
        <groupId>com.example.mymulti</groupId>
        <artifactId>my-multi-parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>
    </parent>

    <artifactId>my-service-web</artifactId>
    <version>0.0.1-SNAPSHOT</version> <!-- 子模块版本可以和父模块保持一致，也可以独立 -->
    <name>my-service-web</name>
    <description>Web module for Spring Boot application</description>

    <dependencies>
        <!-- 引用父项目统一管理的Spring Boot Starter，无需指定版本 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

        <!-- 引用同父项目下的其他子模块，比如 core 和 api -->
        <dependency>
            <groupId>com.example.mymulti</groupId>
            <artifactId>my-service-core</artifactId>
            <version>${project.version}</version> <!-- 引用同项目下的模块，版本通常与当前模块一致 -->
        </dependency>
        <dependency>
            <groupId>com.example.mymulti</groupId>
            <artifactId>my-service-api</artifactId>
            <version>${project.version}</version>
        </dependency>

        <!-- 引用父项目dependencyManagement中定义的lombok，无需指定版本 -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- 如果是可执行的Spring Boot应用模块，需要引入spring-boot-maven-plugin -->
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <!-- 版本在父项目的pluginManagement中统一管理，这里无需指定 -->
            </plugin>
        </plugins>
    </build>
</project>

通过这种方式，你可以在父项目层面控制整个项目的版本、依赖和插件，而子模块则专注于自身的业务逻辑。构建时，在父项目根目录下执行 mvn clean install，Maven会自动处理所有子模块的构建顺序和依赖关系。

为什么选择Spring Boot多模块项目？

我个人觉得，这玩意儿最大的魅力在于它能让一个庞大的系统看起来没那么吓人，像搭乐高积木一样。我们为什么会选择多模块项目，原因其实挺直接的：

• 模块化与解耦： 当一个项目变得越来越大，代码量几何级增长时，如果没有合理的拆分，维护起来简直是噩梦。多模块能把不同的功能、不同的业务领域隔离开来，比如一个模块专门处理用户，一个模块负责订单，它们之间通过明确的接口交互，降低了耦合度。这样一来，修改一个模块的代码，对其他模块的影响就小了很多。
• 依赖管理的一致性： 想象一下，如果你有十几个微服务或者子系统，每个都独立管理自己的Spring Boot版本、Lombok版本、或者各种工具库的版本，那简直是灾难。多模块项目通过父项目的dependencyManagement，可以统一管理所有子模块的依赖版本，避免版本冲突，也省去了每个子模块单独配置的麻烦。
• 构建与部署的灵活性： 有时候，你可能只需要修改其中一个模块，然后只构建和部署这一个模块。虽然Maven默认会构建所有依赖的模块，但如果设计得当，配合CI/CD工具，可以实现更细粒度的部署。而且，对于一些公共的工具类、API接口定义，可以单独抽取成模块，供其他模块引用，避免代码重复。
• 团队协作效率提升： 在大型团队中，不同的团队或个人可以专注于不同的模块开发，互不干扰。只要接口定义清晰，大家就能并行工作，大大提升开发效率。

多模块项目构建中常见的“坑”与应对策略

说实话，每次遇到依赖冲突，都感觉像在玩一场没有硝烟的战争，得一点点排查。多模块项目虽然好用，但它也自带一些“坑”，一不小心就掉进去。

• 依赖冲突： 这是最常见的，也是最让人头疼的问题。不同子模块可能间接引入了同一个库的不同版本，导致运行时错误。
  • 应对策略： 充分利用父项目的dependencyManagement统一管理核心依赖的版本。当出现冲突时，使用mvn dependency:tree命令查看具体的依赖树，找出冲突源，然后通过标签排除掉不想要的依赖，或者在dependencyManagement中强制指定一个版本。
• 模块间循环依赖： 比如模块A依赖模块B，而模块B又反过来依赖模块A。Maven会直接报错。
  • 应对策略： 这通常是设计上的问题。你需要重新审视模块职责，将公共的、被双方都依赖的部分抽取成一个新的独立模块，或者重新规划模块的层次结构。
• 资源文件管理： 比如application.properties、logback-spring.xml等配置文件，每个模块可能都需要。如何统一管理或者隔离，是个需要考虑的问题。
  • 应对策略： 对于公共配置，可以考虑放在父项目下，或者抽取成一个common-config模块。对于特定模块的配置，就放在各自模块的src/main/resources下。Spring Boot的profile机制在这里也很有用，可以为不同环境、不同模块提供不同的配置。
• 父子模块版本不一致： 有时你更新了父项目的版本，但忘记更新子模块pom.xml中标签里的版本。
  • 应对策略： 养成良好的版本管理习惯。在开发阶段，可以使用-SNAPSHOT版本，方便迭代。在发布时，确保所有模块版本同步。CI/CD流程中可以加入版本检查的步骤。
• 构建速度慢： 当模块数量很多时，全量构建一次可能会非常耗时。
  • 应对策略： Maven支持增量构建，比如mvn install -pl :my-service-web -am可以只构建指定模块及其依赖。在日常开发中，可以只构建你当前正在工作的模块。另外，合理利用Maven的Reactor特性，让Maven并行构建没有依赖关系的模块。

如何优化Spring Boot多模块项目的开发体验？

有时候，一个好的IDE配置能省下你不少头发，真的。除了上述的配置和问题解决，还有一些方法能让你的多模块开发体验更上一层楼。

• IDE的深度支持： 像IntelliJ IDEA这样的IDE对Maven多模块项目有非常好的支持。导入父项目后，它能自动识别所有子模块，并正确解析它们之间的依赖关系。利用IDE的导航、重构功能，在模块间跳转和修改会变得异常方便。确保你的IDE Maven配置指向了正确的Maven安装和settings文件。
• 统一的开发规范： 即使是多模块，也要保持代码风格、日志规范、接口定义等的一致性。这有助于团队成员在不同模块间切换时，能快速理解代码。可以引入Checkstyle、PMD等工具在CI/CD中进行自动化检查。
• 公共模块的精心设计： 那些被多个模块引用的common或shared模块，其设计尤为重要。它们应该只包含真正公共的、稳定的内容，比如DTO、枚举、工具类、异常定义等。尽量避免在公共模块中引入过多的业务逻辑或第三方库，以保持其轻量和通用性。
• 自动化测试与CI/CD： 为每个模块编写充分的单元测试和集成测试，并在CI/CD流程中自动化运行。这能确保在代码合并到主分支之前，所有模块的功能都是正常的，及时发现模块间的集成问题。对于多模块项目，CI/CD的自动化构建、测试、部署流程是提升效率的关键。
• 文档与沟通： 尽管代码本身应该尽可能清晰，但对于模块的职责、对外提供的接口、内部实现的关键点，有清晰的文档或者团队内部的定期沟通非常重要。这有助于新成员快速上手，也避免了老成员在模块间“迷路”。

到这里，我们也就讲完了《SpringBoot多模块配置与构建教程》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！