1. 单体项目与多模块项目的差异

从单体走向多模块是 Gradle 项目规模增长中的关键转折点。本章从项目结构、构建速度和代码复用三个维度拆解两者的本质差异，为后续多模块配置与优化建立基础认知。

1.1 项目结构对比

单体项目将所有源码、资源、配置放在同一模块内；多模块项目将功能拆分为独立子模块，每个模块有明确的职责边界。

单体项目典型配置：

// build.gradle（单体）
plugins {
    id 'java'
    id 'application'
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:2.7.0'
}

多模块项目典型配置：

// settings.gradle（根项目）
rootProject.name = 'my-app'
include 'common', 'api', 'service', 'web'

// web/build.gradle
dependencies {
    implementation project(':common')
    implementation project(':api')
    implementation project(':service')
}

1.2 构建速度影响

单体项目每次修改都必须重新编译整个工程。多模块项目借助 Gradle 的增量编译与任务缓存，仅重新构建受影响模块及其依赖链。

• 本地增量编译：Gradle 通过输入/输出快照判断哪些任务需要重跑，多模块粒度更细，跳过无变化模块。
• 构建缓存：各模块可单独缓存，CI 中命中缓存时直接复用产物，节省 60%~90% 构建时间。
• 并发构建：Gradle 并行执行无依赖的模块任务，充分利用多核 CPU。

1.3 代码复用路径

多模块项目通过 Gradle 的 api 与 implementation 配置控制依赖暴露范围，实现精确的复用与封装。

// :common/build.gradle
dependencies {
    api 'com.google.guava:guava:31.1-jre'
}

// :api/build.gradle
dependencies {
    implementation project(':common')  // 使用 common 中的 Guava，但不会传递给 :web
}

依赖传播原则：implementation 依赖的 api 依赖会透传，避免重复 jar 冲突；compileClasspath 与 runtimeClasspath 分离，提供更快的配置解析。