Quarkus项目从Maven切换到Gradle：多模块构建提速与优化实践

1. 为什么我在 Quarkus 项目里从 Maven 切到了 Gradle

1.1 事情要从一次"又是 Maven 的问题"说起

先说背景。我之前用 Quarkus 写微服务，默认跟随官方文档走了 Maven。Quarkus 对 Maven 的支持相当成熟，文档齐全，社区里绝大多数示例都是 Maven 工程。按理说没有换工具的必要，直到我维护一个多模块项目，每个模块之间都有依赖，模块数量一多，Maven 的"全量重建"问题开始变得非常扎眼。

具体场景是这样的：我改了公共模块里的一个工具类，然后重新构建应用模块，Maven 会把整个 reactor 里相关的模块都重新跑一遍编译、测试、打包流程。如果只是本地开发，勉强能忍；一旦在 CI 上频繁跑构建，一次构建三五分钟起步，这个成本就很痛了。更难受的是，Quarkus 的开发模式（dev mode）虽然热重载做得好，但 Maven 在增量编译这块一直不太聪明——它不做内容哈希对比，只靠时间戳和文件状态来判断是否需要重编，改一个类经常触发大范围重编。

后来试了 Gradle，情况立刻不一样。Gradle 的增量构建和构建缓存机制是深度集成在任务图里的，它知道你的编译任务输入是哪些文件、输出是哪些 class 文件，只要文件内容没变，就算时间戳变了也照样跳过。这种"聪明"的程度，在 Quarkus 这种依赖大量注解处理和字节码生成框架上，体验差距是肉眼可见的。

1.2 Gradle 的三种能力正好补上 Quarkus 的短板

Quarkus 的构建过程有一个显著特点：它在编译期做大量工作，包括注解处理器生成字节码、构建 Jandex 索引、分析依赖、生成 native image 的中间产物。这些工作如果每次都从头跑一遍，构建时间会非常长。Gradle 的三种机制能精准地把这部分的成本降下来。

第一种是配置缓存（configuration cache）。Gradle 在 7.4 之后默认推荐开启配置缓存，它能把你整个构建脚本的配置阶段结果缓存下来，下次直接复用，只有任务执行阶段才真正跑。Quarkus 的构建脚本里有不少插件逻辑，配置阶段耗时不算短，配置缓存开了之后，构建启动明显轻快。

第二种是构建缓存（build cache）。本地缓存已经是好东西了，更狠的是远程构建缓存：团队里任何一个人构建过的产物，其他人直接拉取，编译这一步都省了。对 Quarkus 这种产物确定性较高的框架来说，远程缓存命中率相当可观。

第三种是守护进程（daemon）和并行执行。Gradle 默认起一个常驻的守护进程，JVM 不会反复启动，依赖解析的结果也在内存里缓存着。多模块项目里，独立模块间的任务可以并行跑，不比 Maven 那种"老老实实按依赖顺序排队执行"的方式，时间上能省一截。

我后来在团队里做了个简单对比：同一个多模块 Quarkus 项目，用 Maven 做一次全量 package，耗时约 3 分 20 秒；用 Gradle 冷构建首次约 2 分 40 秒，二次构建直接降到 40 秒以内。第二次构建因为增量构建和配置缓存生效，省掉了一大半活。这个差距在 CI 上滚一圈就能体会到，开发机上更是轻松不少。

2. Quarkus Gradle 插件环境准备与第一个项目

2.1 环境和版本组合的选择

开始之前先把版本关系说清楚。Quarkus 的 Gradle 插件从 Quarkus 2.x 时代开始就足够稳定了，到了 3.x 时代已经完全跟 Maven 插件平起平坐。目前主流组合是：

• JDK 17 或 21（Quarkus 3.x 要求 JDK 17+）
• Quarkus 3.x 最新稳定版
• Gradle 8.x（推荐 8.5 以上，配置缓存体验更好）

注意 Gradle 版本不是越新越好。Quarkus 插件对 Gradle 版本有一定的验证范围，比如 Quarkus 3.8 之前有些版本对 Gradle 8.6+ 的支持存在小问题，升级前最好看一眼 Quarkus 官方文档里 Gradle 兼容性表格。我自己吃过亏：当时图新鲜升级了 Gradle 8.10，结果 quarkusBuild 任务偶尔报一些奇怪的编译期错误，回退到 8.7 就好了，后面才确认是插件内部某个任务对 Gradle API 的兼容问题，等 Quarkus 版本更新后才解决。

另外，JDK 版本和 Gradle JVM 版本要区分开。Gradle 守护进程有自己运行的 JVM，项目编译也有自己的 Java 版本设置。如果你用 IDEA 打开项目，报 The project's Gradle version 8.5 is incompatible with the Gradle JVM version 21 之类的错误，多半是 Gradle 运行时 JVM 版本不合适。建议把 Gradle JVM 设置为 JDK 21，项目编译的 Java 版本设置为 17 或 21，两边不要混。我用的是 JDK 21 跑 Gradle 守护进程，项目本身编译目标 17，完全没问题。

2.2 生成项目的几种方式

Quarkus 官方推荐用 code.quarkus.io 网页生成项目，也可以装 Quarkus CLI 命令行生成，我两种都用过。网页端的优势是可视化选择扩展，勾选完直接下载 zip；CLI 的优势是方便集成进脚本，可以一条命令拉出一个带好扩展的项目。

我的建议是：就算你打算从零手写 build.gradle.kts，也不要真的从空文件开始。因为 Quarkus Gradle 插件需要依赖平台 BOM（Bill of Materials）来管理所有 Quarkus 扩展的版本，这个 BOM 的坐标和版本号手写容易出错。生成一个最基础项目，再在此基础上改，踩坑概率最低。

CLI 生成命令大概是：

bash复制quarkus create app com.example:demo-app --extension=resteasy-reactive,reactive-routes -b gradle

-b gradle 代表生成 Gradle 构建文件，不带这个参数默认是 Maven。生成完成后你会看到 build.gradle.kts、settings.gradle.kts、gradle.properties、gradlew 和 gradlew.bat 等文件。这里提一句，无论什么方式生成，gradlew 和 gradlew.bat 都建议提交进 Git。团队协作时统一 Gradle 版本，比让每个人手动装 Gradle 再祈祷版本一致要靠谱得多。

2.3 逐个拆解 build.gradle.kts 的关键配置

Gradle 生成出来的 build.gradle.kts 里，最重要的几块是插件声明、依赖管理和任务配置。

kotlin复制plugins {
    id("io.quarkus.platform:quarkus-gradle-plugin:3.14.0")
}

dependencies {
    implementation enforcedPlatform("io.quarkus.platform:quarkus-bom:3.14.0")
    implementation("io.quarkus:quarkus-resteasy-reactive")
    implementation("io.quarkus:quarkus-resteasy-reactive-jackson")
}

注意两点。一是 Quarkus 插件 ID 比较长，是 io.quarkus.platform:quarkus-gradle-plugin，不是 io.quarkus。二是依赖中必须引入 enforcedPlatform 声明的 BOM，这样所有 Quarkus 扩展都不用写版本号。enforcedPlatform 和普通 platform 的区别在于前者会强制覆盖依赖冲突中的版本，确保所有 Quarkus 扩展版本一致。Quarkus 框架对扩展间版本一致性要求很高，混用不同版本的扩展大概率出诡异问题，建议无脑用 enforcedPlatform。

settings.gradle.kts 里可以配置插件管理仓库，我在国内环境通常会加腾讯云镜像来加速插件下载：

kotlin复制pluginManagement {
    repositories {
        maven("https://mirrors.cloud.tencent.com/nexus/repository/maven-public/")
        gradlePluginPortal()
    }
}

2.4 启动开发模式：quarkusDev 与热重载的实际体验

项目搭好以后，最常用的命令不是 build，而是：

bash复制./gradlew quarkusDev

这个任务会启动开发模式。Quarkus 的开发模式相当神奇，你改了 Java 源码、资源文件甚至是 application.properties，保存后它会自动编译并热重载。关键是它的重载不是传统 Spring 那种重启应用，而是直接在运行中的 JVM 上做类替换和配置更新，速度极快。

我第一次跑 quarkusDev 的时候，对它的热重载速度半信半疑，特意写了一个返回当前时间戳的 REST 接口，改完代码保存，然后立刻用 curl 请求，接口返回的内容已经是新逻辑了，这个响应速度确实比常规"手动重启"舒服太多。

Maven 也有对应的 mvn quarkus:dev，两者功能上没差。区别在于 Gradle 模式下，如果你同时开着 Android Studio 或 IDEA 的 Gradle 同步，两个进程不会互相干扰，因为 Gradle 的并发锁管理比 Maven 更细粒度。我在多 IDE 窗口同时打开项目时，Maven 偶尔会因为 .m2 目录下本地仓库的锁而卡住，Gradle 这边基本没遇到过。

3. 在 Quarkus 开发中 Gradle 与 Maven 的真正分水岭

3.1 构建模型：任务图与生命周期的本质差异

Maven 的构建模型是生命周期（lifecycle），从 validate 到 compile、test、package、verify 一路按阶段推进。每个阶段绑定了一组插件目标（goal），比如 compile 阶段会执行 maven-compiler-plugin 的 compile 目标。这个模型的设计哲学是"统一标准、约定优先"，好处是学习成本低——你看一个项目的 Maven 配置，基本能猜到整体结构。

Gradle 的构建模型是任务图（task graph）。你在脚本里定义了一个个任务，Gradle 根据任务之间的依赖关系构建一个有向无环图，然后按拓扑序执行。这带来一个关键差异：Gradle 可以精确知道"我改了 B 模块，只需要重新编译 B 和依赖 B 的模块，其他模块的任务可以跳过"。Maven 的 reactor 策略虽然也知道模块依赖，但它执行粒度粗，经常一个生命周期阶段就把所有模块都过一遍。

放到 Quarkus 场景里，这个差异被放大了。Quarkus 的构建过程中有一个环节是字节码处理和索引生成，如果在 Maven 中每次 compile 阶段都对全部模块做一遍，代价很高。Gradle 因为任务粒度细，可以只对变更的模块做字节码处理，其他模块直接复用上次的产物。

3.2 增量构建与构建缓存：改动一行代码需要多少秒

我在本地跑过一次实测。项目是一个带 JPA、REST 和消息推送的中型 Quarkus 服务，代码行数大概 1 万行出头。改动一行日志语句后，不重启应用，直接跑构建。

Maven 从 compile 到 package 大约耗时 22 秒。Gradle 同样改动一行后跑 build，输出显示 4 个任务执行、18 个任务被跳过，实际耗时约 6 秒。这个差距主要来自 Gradle 的增量构建机制——它通过任务输入输出的快照（snapshot）判断是否需要重新执行，未变更的文件不会重新编译。

再叠加构建缓存后，情况更极端。如果 CI 和开发机构建缓存互通，我第一次在 CI 上构建好的字节码和 Fat Jar，开发机上重新构建时可以直接命中缓存，quarkusBuild 任务直接用的 CI 产物，本地构建时间甚至能压到 1 秒以内。这在"频繁改代码、跑测试、验证"的本地开发循环中非常顶用。

3.3 配置成本对比：XML 与 Kotlin DSL 的选择

Maven 的 XML 配置在表达复杂逻辑时比较痛苦。你要写条件判断、动态版本解析、多环境配置，得叠加 profile、properties、插件 configuration 这些 XML 元素，写出来的配置既冗长又难调。碰到"release 构建要额外打一个 Jandex 索引、开发构建不要"这类需求，Maven 里要搞 profile 嵌套，维护起来相当头疼。

Gradle 的 Kotlin DSL 是程序化配置，可以写变量、写函数、写条件分支，配置本身是一段代码。同样是条件判断，Kotlin DSL 里一个 if 就搞定了。比如我只想在 release 构建时打 native image：

kotlin复制tasks.quarkusBuild {
    if (project.hasProperty("native")) {
        nativeArgs.set(mapOf("enabled" to "true"))
    }
}

这比 Maven profile 里写一堆 <activation> 要直观得多。

当然 Gradle 也不是没有代价。Groovy DSL 时代学习曲线略陡，Kotlin DSL 虽然类型安全，但 IDE 的自动补全有时会卡，脚本编译也需要一点时间。相比之下，Maven 的 XML 格式简单，随便找个教程都能快速上手。如果你是一个追求"配置可见性"的团队，Maven 反而更合适。我个人现阶段主要精力放在多模块项目上，所以更倾向 Gradle 的表达能力。

3.4 Quarkus 扩展管理的差异：BOM 与 platform 的处理方式

Quarkus 扩展的依赖关系里，有一个重要的设计：所有扩展的依赖都由 quarkus-bom 统一管理版本。Maven 里直接引入 BOM 再用 <dependency> 声明扩展即可；Gradle 里则要用 enforcedPlatform 或 platform 引入 BOM，再在 dependencies 块里正常声明扩展。

两者有个细微差别：Maven 的依赖仲裁（dependency mediation）是"就近原则"，指按依赖树的深度来决定谁胜出；Gradle 的趋势是直接用enforcedPlatform 强有力地覆盖版本，把所有 Quarkus 扩展的版本统一到 BOM 指定版本，冲突处理策略更刚性。对 Quarkus 这类严格要求扩展版本对齐的框架，Gradle 的这种强制覆盖反而更省心。

另外，Gradle 里切换 Quarkus 版本只需要改 BOM 和插件两处，Maven 需要改 BOM 和插件各一处（因为 Maven 插件也是通过 <plugin> 声明版本），两者差别不大。但 Gradle 可以在 gradle.properties 里集中管理版本属性，比如：

properties复制quarkusVersion=3.14.0

然后在构建脚本里引用，升级版本时只改一处，批量更新多模块项目时的操作成本低很多。

4. Gradle 构建优化：从 40 秒到 5 秒的调优记录

4.1 先解决依赖下载：国内镜像配置

Gradle 在国内网络环境下最烦人的问题之一就是依赖下载慢。如果你一开始没配镜像，首次构建可能卡在下载依赖和大批插件上，一个 3 分钟能装完的项目，硬生生拖到 20 分钟。这里我给出一个实测有效的镜像方案。

settings.gradle.kts 里配置仓库：

kotlin复制dependencyResolutionManagement {
    repositories {
        maven("https://mirrors.cloud.tencent.com/nexus/repository/maven-public/")
        maven("https://maven.aliyun.com/repository/public/")
        maven("https://maven.aliyun.com/repository/central/")
        maven("https://maven.aliyun.com/repository/gradle-plugin/")
        mavenCentral()
    }
}

这个顺序是有讲究的。腾讯云的 nexus 镜像聚合了中央仓库和常用第三方仓库，覆盖面广；阿里云的 public 仓库也聚合了 central 和 jcenter；gradle-plugin 仓库是插件专用的镜像。把镜像放前面，Gradle 会先访问镜像，只有镜像里没有的组件才会回源到 Maven Central，这样能避免国际网络延迟。

还有一个常见痛点：Gradle 发行包本身下载慢。如果你用 gradlew 首次构建，Gradle 需要从 services.gradle.org 下载完整的发行包，这个下载经常超时。解决方法是改 gradle-wrapper.properties 里的 distributionUrl 为腾讯云镜像：

properties复制distributionUrl=https\://mirrors.cloud.tencent.com/gradle/gradle-8.7-bin.zip

改完后重新执行 ./gradlew，发行包就从国内镜像拉取了，速度从几百 KB 直接跑到几 MB。镜像站 CDN 通常比国外源稳定很多，实测再也没有出现过 java.net.SocketTimeoutException 之类的下载超时。

4.2 构建缓存与并行构建

构建缓存算是我调优过程中收益最大的一步。在 gradle.properties 里打开：

properties复制org.gradle.caching=true
org.gradle.parallel=true

开启后，本地构建缓存生效。像 Quarkus 的 quarkusBuild 任务，它的输入包含所有编译后的 class 文件和资源文件，输出是最终的 jar 包。只要输入没变，任务直接命中缓存，不再执行实际的打包逻辑。

如果想在团队内共享缓存，可以搭一个远程构建缓存服务，常见的有 Gradle Enterprise、Develocity 或开源项目 Build Cache Node。配置远程缓存地址后，团队成员之间可以共享产物。我这里不做详细展开，因为搭建远程缓存服务的成本相对高，小团队先把本地缓存和并行构建用起来，收益已经不小。但前提是任务必须声明好输入输出，Quarkus 插件本身在这方面封装得不错，默认就能吃上缓存红利。

并行构建对多模块项目尤其有效。Quarkus 多模块里各个业务模块之间往往只有依赖关系、没有并行冲突，Gradle 的并行任务执行可以同时跑多个模块的编译，避免 CPU 空闲。实测四核八线程机器上，把 org.gradle.workers.max 设为 4，全量构建时间又缩短了不少。

4.3 配置缓存，一劳永逸

Gradle 7.4 起把配置缓存作为一个稳定特性，到 8.x 已经非常成熟。开启方式也很简单：

properties复制org.gradle.configuration-cache=true

配置缓存的核心思想是：项目的配置阶段（即执行 build.gradle.kts 脚本的那段逻辑）在整个构建期间只执行一次，结果存到缓存里，后续构建直接复用。在 Quarkus 这个场景里，配置阶段涉及的插件解析、扩展配置、任务注册都很耗时，缓存命中后，构建启动阶段几乎感觉不到延迟。

需要注意的是，配置缓存对构建脚本有约束：不能使用系统属性、环境变量等非确定性输入来动态决定任务内容，否则 Gradle 会警告或禁用缓存。我遇到过的典型问题是插件里用了 System.getProperty 读取自定义参数，这会让配置缓存失效。对于自己写的自定义任务，建议把外部输入声明为任务输入属性，而不是直接在配置阶段读取环境变量。

开启配置缓存后，第一次构建会提示"Configuration cache entry stored"，第二次执行时如无变化，会显示"Reusing configuration cache"。我在项目里实测，quarkusDev 启动时间从大约 6 秒降到 2 秒左右，对于频繁启动开发模式的场景，绝对属于体验级别提升。

4.4 优化 quarkusBuild 的产出物：知道哪些任务可以砍掉

Quarkus 构建流程里有两个容易忽略的耗时点，一个是测试任务的执行，另一个是生成 quarkus-app 目录时的拷贝操作。

在 CI 上，如果你只想验证"能否构建"，不跑单元测试，可以在构建命令中排除测试：

bash复制./gradlew build -x test

或者更细致一点，只跳过 Quarkus 的测试任务（默认叫 quarkusTest）：

bash复制./gradlew quarkusBuild -x quarkusTest

另外，Quarkus 构建时可以控制是否生成原生镜像运行的字节码、是否进行 -parameters 保留等。针对不需要的产物可以关闭。比如开发环境不需要生成 uber-jar，就不需要额外配置；如果需要打可执行 jar，可以在 build.gradle.kts 里：

kotlin复制tasks.quarkusBuild {
    uberJar.set(true)
}

要不要 uber-jar 看部署环境。如果你的 CI 会把所有依赖传到运行环境，普通薄 jar 配合 quarkus-app/lib 目录更合理；如果要做一个单文件部署包，uber-jar 更方便。我在生产环境用的是普通模式，因为我们的运行环境有独立的依赖目录，打 uber-jar 反而让 OCI 镜像层缓存失效。

4.5 优化效果对比：一次完整的实测数据

为了让这组优化更有说服力，我记录了一个中型项目的优化前后对比，环境是 2023 年款 MacBook Pro（M2 Pro 芯片，16GB 内存），项目是 8 个模块的 Quarkus 3 应用。

最大的惊喜在二次构建，几乎是"秒开"。这个效果主要归功于配置缓存和任务增量快照双管齐下。对于频繁往返于编译器和终端之间的开发流程，5 秒一轮构建的节奏完全可以接受。

5. 实测中遇到的常见坑与排查思路

5.1 插件版本与 Quarkus 平台版本不匹配

这个坑比较隐蔽。plugins 块里的 quarkus-gradle-plugin 版本和 dependencies 块里的 quarkus-bom 版本如果不一致，大概率会出现 NoSuchMethodError 或 Task with name 'quarkusBuild' not found 这类错误。我遇到过一次：BOM 是 3.8.1，插件是 3.6.0，构建时插件尝试调用一个新版 API 不存在的方法，直接崩溃。

排查思路很简单，把所有涉及 Quarkus 版本的地方统一。建议把版本号放到 gradle.properties 里：

properties复制quarkusPlatformVersion=3.14.0
quarkusPluginVersion=3.14.0

然后分别引用。理论上两个版本通常保持一致，但因为插件和 BOM 的版本节奏偶尔会有错位，独立管理更能及时发现差异。

5.2 本地仓库缓存导致依赖解析失败

这个问题在 Maven 和 Gradle 里都会遇到，但表现不太一样。Gradle 默认依赖解析不完全缓存，每次构建都会访问仓库检查快照版本是否更新。如果你在开发中使用 SNAPSHOT 版本的 Quarkus 扩展，会反复从仓库拉取最新快照。网络抖动时，快照拉取失败会导致构建失败，即使本地已经有可用版本。

我建议在 gradle.properties 里配置缓存策略：

properties复制systemProp.org.gradle.internal.http.socketTimeout=120000
systemProp.org.gradle.internal.http.connectionTimeout=120000

把超时时间调大一点，可以避免网络波动导致的构建中断。如果你使用固定版本而不是 SNAPSHOT，Gradle 默认会缓存，不会再访问仓库，这里的行为比 Maven 更"聪明"。

5.3 Quarkus 资源文件没有生效

还有一个容易踩的坑：Quarkus 的资源过滤（resource filtering）在某些场景下，Gradle 默认不把 src/main/resources 里的文件复制到输出目录，或者配置文件里的 @variable@ 占位符没有被替换。

Maven 里配置资源过滤需要在 pom 里显式声明 <resources>；Gradle 里更简单，processResources 任务的 expand 方法可以处理占位符替换：

kotlin复制tasks.processResources {
    expand(project.properties)
}

但注意 expand 会把所有占位符当成 Groovy 模板表达式去解析，如果你的配置文件里有 $ 或者 @ 这种合法字符，会被误替换导致内容损坏。所以不要对全部资源启用 expand，只对需要替换的配置目录开启：

kotlin复制tasks.processResources {
    filesMatching("application.yml") {
        expand(project.properties)
    }
}

这个细节在 Quarkus 项目中很实用。因为 application.properties 或 application.yml 里经常有配置项引用环境变量，如果误用了全量 expand，配置里的特殊字符会被当成模板处理，导致启动报错。

5.4 Gradle 守护进程内存配置

构建 Quarkus 项目时，Gradle 守护进程默认堆内存只有 1GB 左右，如果项目模块多、依赖多、还开着配置缓存，这个大对象分配频繁的场景下，守护进程容易频繁触发 Full GC，构建变慢且不稳定。

建议在 gradle.properties 里调整：

properties复制org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1g -Dfile.encoding=UTF-8

如果你用的是 Apple Silicon 芯片，加一行：

properties复制org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1g -Dfile.encoding=UTF-8

加了 -Dfile.encoding=UTF-8 是防止在中文环境或者使用某些资源规则时出现编码错误，这个坑在读取资源文件时遇到过。另外守护进程可以常驻，不需要频繁重启，quarkusDev 模式下重启守护进程会让热重载失效，所以建议一个项目固定一个守护进程。

5.5 关于 Gradle Wrapper 版本不匹配的提示

Gradle 升级时最容易出现的是 wrapper 版本与本地配置不匹配。比如本地装了 8.7，项目 wrapper 写的是 8.10，跑 ./gradlew 时它会自动下载对应版本，这时如果网络慢或镜像没配好，很容易卡住。建议团队升级 Gradle 版本时，要同步更新 gradle-wrapper.properties，并且用 ./gradlew wrapper --gradle-version 8.7 这样的命令统一生成 wrapper 文件。

还有一点小技巧：如果你用 IDEA 打开 Gradle 项目，经常遇到 IDEA 自带 Gradle 版本与 wrapper 不一致，导致 Sync 失败。解决办法是在 IDEA 设置里，把 Gradle 的 distribution 配置为 Wrapper，让 IDEA 使用 wrapper 指定版本。这不算 Quarkus 特有，但项目里同时存在多套 Gradle 版本时，这个设置能省很多不必要的排错时间。

6. 写在最后的个人体会

从 Maven 切换到 Gradle 不是一道简单的二选一题。如果你的 Quarkus 项目是单模块、依赖简单、团队对 Maven 工具链已经很熟悉，继续用 Maven 完全合理，毕竟 Quarkus 官方对 Maven 的支持已经非常成熟。但如果你正在维护多模块项目、频繁迭代、对本地构建体验和 CI 时间有要求，Gradle 的增量构建、配置缓存和任务图模型确实能让日常开发轻松不少。

我个人实测下来的体会是：Gradle 的"高级感"不在第一眼，而在你开始改第三十个依赖、加第五个模块、调第二次 CI 配置的时候。它给你的自由度和精细控制，在复杂项目里会越来越值钱。而 Quarkus 本身又是一种偏向"构建期做决策"的框架，和 Gradle 的工程能力组合起来，属于互相成就的组合。

最后再分享一个小经验：搭建完 Gradle 构建后，建议把 .gradle 目录和 build 目录加进 .gitignore，不要提交进版本库。这看起来简单，但我见过不少项目把 build 目录误提交，导致同事拉代码后冲突一堆，最后搞了一天排查确实得不偿失。这些小细节，往往比选哪个构建工具更影响你的开发幸福感。