Gradle 构建基础回顾
做 Android 或 Java 后端的朋友，对 Gradle 应该都不陌生。它本质上就是一个自动化构建工具，但跟早些年的 Ant 或 Maven 比，灵活性和性能都好不少。我最初接触 Gradle 时还挺抵触的——毕竟 Maven 的约定大于配置用习惯了，突然要学一套新的 DSL。但真正上手后，我发现它那种基于任务的编排方式，确实更贴近现代项目的复杂度。
说白了，Gradle 的核心价值就两点：一个是基于 Groovy 或 Kotlin 的强大 DSL，让你能写出几乎任何自定义逻辑；另一个是它基于 DAG（有向无环图）的任务依赖解析，天然支持增量构建和并行执行。这两点加在一起，让构建脚本不再是死板的 XML 配置，而更像一段可编程的流程。
构建生命周期——一张图帮你理清
每次执行 gradlew build，背后都经历了三个阶段。很多新手会忽略这个流程，导致任务依赖写错或配置执行顺序混乱。我个人习惯把生命周期画成一张图贴在工位旁边，你想想看，知道每个阶段在做什么，调试起来会轻松很多。
Gradle Wrapper——团队协作的基石
你可能遇到过这种情况：一个项目本地能编译，同事电脑上就报错。原因往往是 Gradle 版本不统一。Gradle Wrapper 就是解决这个问题的标准方案。它会把 Gradle 分发版本锁定在 gradle-wrapper.properties 文件中，团队所有人拉下代码后执行 ./gradlew 都会自动下载指定版本。
我曾经在一个老项目里吃过一次亏：项目用了 Gradle 4.x，新同事没注意全局环境装了 7.x，结果构建时一堆不兼容的 DSL 报错。后来强制要求所有项目都必须用 Wrapper，再也没出过类似问题。
gradlew、gradlew.bat、gradle/wrapper/，这些都应该提交到 Git 仓库。不要加 .gitignore，否则失去了版本锁定的意义。
build.gradle 结构——核心配置一瞥
一个典型的 build.gradle 脚本，本质上就是一个由 Groovy 或 Kotlin 构成的脚本。它通过 plugins、repositories、dependencies 等闭包组织配置逻辑。我习惯把 build.gradle 分成三个区块：项目元信息、插件和仓库、任务和自定义逻辑。
plugins {
id 'java'
id 'application'
}
repositories {
mavenCentral()
}
dependencies {
implementation 'com.google.guava:guava:31.1-jre'
testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'
}
application {
mainClass = 'com.example.Main'
}
task printVersion {
doLast {
println "当前版本: ${version}"
}
}
注意 dependencies 里的 implementation 和 testImplementation 是 Java 插件提供的配置（configuration）。每个配置对应一组依赖，它们会在不同阶段被使用。举个例子，implementation 下的依赖只对当前模块可见，而 api 则会泄漏给下游——这个区别在实际项目中很容易踩坑。
| 配置名 | 作用 | 常用场景 |
|---|---|---|
implementation | 依赖仅对该模块编译时可见，运行时仍存在 | 内部实现细节，不暴露给消费者 |
api | 依赖同时暴露给消费者 | 公共接口中使用的库 |
compileOnly | 仅编译时需要，运行时由容器提供 | Servlet API、注解处理器 |
testImplementation | 仅测试代码所需 | JUnit、Mockito |
implementation，导致下游模块编译报错。解决办法记住一个原则：如果你不确定是否要暴露给外部，先用 implementation，等编译报错时再改成 api。
Gradle 与 Maven 的对比
很多团队从 Maven 转到 Gradle，我当年也是。Gradle 最大的优势是性能：它支持增量编译、并行任务、构建缓存。而 Maven 基于 XML 的配置虽然严谨，但扩展性差。下面这个表格可以快速帮你理解差异：
| 特性 | Maven | Gradle |
|---|---|---|
| 构建脚本语言 | XML（声明式） | Groovy / Kotlin（DSL） |
| 依赖管理 | 依赖坐标（GAV） | 相同概念，但支持动态版本 |
| 任务模型 | 生命周期阶段和目标 | Task 图驱动，灵活度更高 |
| 性能 | 慢（无增量编译） | 快（增量、并行、缓存） |
| 扩展 | 插件（XML 配置） | 插件 + 自定义 Task + 脚本 |
选择哪个工具其实取决于你的团队习惯和项目规模。如果你需要高度定制的构建逻辑，Gradle 会是一个更好的选择。但我个人建议，即使你还在用 Maven，也了解一下 Gradle 的 Wrapper 机制——它后来也被 Maven Wrapper 借鉴了。