名词解释教学工作区 · 课程 0015 · 形态 单概念 · 约 6 分钟 · 前置:0004 · Node.js / npm / pnpm(先分清"装包"的角色) · 相关:0016 · 静态部署与其它部署 · 2026-10-01

Gradle:从源码到产物,这条流水线谁在管

1 | 定义

Gradle(构建工具 build tool):把「从源码到产物」要做的事拆成一个个 任务 task,再按任务之间的依赖排成一张 依赖图 dependency graph 依次执行, 顺手替你解析、下载要用到的外部库。它跟包管理器的分工是: 一个管「装什么」,一个管「做出什么」。 像厨房里那张流程单:从原料到出餐要洗、切、炒,谁先谁后、切过的就不必再切; 它管的就是这条线 —— 你只说一句「出餐」,它照着单子把每道工序派下去。

2 | 它解决什么麻烦

没有构建工具的时候,一个项目从源码走到能交付,中间全是没人愿意手管的琐事:

• ① 编译命令又长又讲究顺序。先编哪个模块、带哪个参数、产物放哪儿,少一步就报一串看不懂的错。
• ② 要用的库得自己找、自己下、自己对版本。同一个库被两个模块要求不同版本,靠人脑算不现实。
• ③ 「在我机器上明明能构建」。换台机器、换个同事,工具版本或仓库地址一变结果就不同,只能靠问人。
• ④ 只改了一个文件,整条路却要重走一遍。没有「上次算过」这件事,每次都是全量重来。

这四件事有个共同点:它们属于流程,不属于程序本身。构建工具专门接管这一段。

3 | 它怎么解决

构建脚本 你写下的规则 -> 任务 task 一件可执行的事 -> 依赖图 dependency graph 谁必须排在谁之前 -> 增量构建 incremental build 输入没变就沿用上次 -> 产物 build 可交付的那份东西

• ① 一切都写成任务。「编译」「测试」「打包」各是一个任务;你只请求最后那个,前面的按依赖自动排。
• ② 依赖被展成一张图。Gradle 自己算出拓扑顺序,同层的任务还能并行 —— 谁不依赖谁,它分得清。
• ③ 每个任务记下输入与输出。输入没变就直接沿用上次结果,这就是 增量构建 incremental build 让第二次构建变快的原因 —— 它省的是重复劳动, 和算法本身的复杂度是两本账。
• ④ 构建配置是代码。用 Groovy 或 Kotlin DSL 写,文件通常是 build.gradle 或 build.gradle.kts;多模块项目再加一个 settings.gradle 列出有哪些模块。
• ⑤ 插件把常见流程打包。Java、Kotlin、Android 各有一套 插件 plugin, 引入即得「编译 + 测试 + 打包」整条链,你只调参数。
• ⑥ 依赖解析加本地缓存。先从仓库(如 Maven Central)下载到本机缓存,再算出一组版本不冲突的组合; 下次直接命中缓存,不重复下。
• ⑦ Wrapper 把工具版本钉在项目里。仓库里带一份 Gradle Wrapper (命令 gradlew 加几个配置文件),别人克隆下来用的是同一个 Gradle 版本,而不是他本机装的那份。

4 | 用它的代价

• ① 构建脚本是一门要另外学的语言。老脚本用 Groovy,新写法用 Kotlin DSL,错一行整条构建就停; 这套知识跟你的业务代码毫无关系。
• ② 守护进程与缓存吃内存和磁盘。默认留一个常驻进程让后续构建更快,依赖缓存放在用户目录里越滚越大; 内存紧张的机器上,这两样都得额外打点。
• ③ 插件版本兼容矩阵很烦。Gradle 版本、插件版本、JDK 版本互相挑,升一个往往要跟着升一串, 报出来的错还指不到根上。
• ④ 首次构建慢。要下插件、下依赖、建缓存,「快」是第二次才见得到的东西;冷机器上尤其明显。

5 | 真实使用场景

场景一:本地跑构建与测试。

./gradlew build        # 按依赖跑完编译、测试、打包,产物进 build/
./gradlew test         # 只跑到测试;已经算过的步骤自动跳过
./gradlew bootRun      # Spring Boot 项目:直接起服务,不必先手动打包

命令前那个 ./gradlew 就是项目自带的 Wrapper,所以第一次跑它会先把对应版本的 Gradle 拉下来。

场景二:CI/CD 流水线里构建。

./gradlew --no-daemon build   # 一次性环境:跑完就退出,不留常驻进程
./gradlew --offline build     # 依赖已在缓存里时,不联网也能构建

流水线用的是用完即弃的容器,常驻进程留不下来,反而成了纯开销,所以显式关掉;要让结果可复现, 还得把 Gradle 版本与依赖来源一起锁死。

场景三:多模块与 Android 项目。

一个仓库拆成 app/、core/ 等多个模块时,settings.gradle 列出成员, ./gradlew :app:build 这种带路径的任务名可以只构建其中一块。Android 项目也是同一套配置, 只是插件换成了 Android Gradle Plugin —— 这也是 Gradle 最常见的一张门面。

6 | 和相近的东西怎么分

先问一句:你要解决的是「怎么编」,还是「编的流程谁来管」? 再问一句:这句话说的是一步,还是整条路?

一句话分工:包管理器管「装」,编译器管「翻」,构建工具管「编排整条路」,部署工具管「送出去」。

7 | 常见误解

• ① 「构建工具就是编译器。」错在把一步当成整条路:编译只回答「把源码变成指令」, 取依赖、跑测试、打包、跳过没变的步骤,全是它之外的事。
• ② 「Gradle 只能用于 Android。」它确实在 Android 里最常见,但后端 Java / Kotlin 服务、 纯 JVM 类库同样用它;Android 只是它的一张门面,不是它的范围。
• ③ 「换成 Maven 就不用学构建配置了。」换掉的只是写法(XML 换 Groovy / Kotlin DSL), 任务、依赖、增量这些概念一个都跑不掉;不懂它们,换哪个工具都会卡在同一处。
• ④ 「构建报成功就说明没问题。」构建只保证「你写的步骤都做完了」;漏写一步、 或者你让它跳过测试,它照样报成功 —— 所以要看每个任务的结果,而不是最后那一句完成。

8 | 练习

三题自测,每题只有一个正确选项;选完立刻看到解释。