配置阶段拖慢构建是因为gradle必须先解析所有build.gradle、创建任务、建立依赖图，即使只运行clean也会全量加载模块；启用configureondemand或configuration-cache可按需配置并缓存结果。
为什么配置阶段会拖慢整个构建
Gradle 在执行任何任务前，必须先完成「配置阶段」：解析所有 build.gradle 文件、创建任务对象、建立依赖图。哪怕你只运行 ./gradlew clean，它依然会完整配置所有模块（包括未参与本次构建的子项目）。中大型项目里，几十个模块全被无差别加载，光是读取和解析 DSL 就可能耗时数秒——这和任务是否最终执行无关，纯属冗余开销。
启用 on-demand 配置模式
让 Gradle 只配置真正需要的模块，而不是一股脑全加载。关键配置项是 org.gradle.configuration-cache=true（Gradle 8.4+ 推荐）和更直接的 org.gradle.configureondemand=true（旧版兼容性更强）。
-
org.gradle.configureondemand=true：仅对当前构建目标所依赖的模块执行配置，跳过其他子项目。适用于多模块项目且模块间依赖较清晰的场景 -
org.gradle.configuration-cache=true：不仅跳过未用模块，还缓存整个配置过程的结果（包括插件应用、扩展注册等），下次构建可复用。Gradle 9+ 默认启用，但 Java/Android 项目需确保脚本是惰性友好的（比如避免在配置块里调用project.version这类强制求值操作） - 二者不互斥，可同时开启；但若项目用了大量动态逻辑（如
allprojects { ext.xxx = ... }或非惰性插件），configuration-cache可能失败并报Configuration cache is not supported错误
避免配置阶段的副作用代码
配置阶段不是执行阶段，任何在任务定义体外、或未包裹在 doFirst/doLast 中的逻辑，都会在每次构建启动时无条件执行。
- 禁止在
build.gradle顶层或tasks.register外部做 IO 操作，例如new File("some.properties").text或网络请求 - 不要在
android {}或dependencies {}块里写条件判断并抛异常（如检查环境变量缺失就throw new GradleException），这会让所有构建都失败，哪怕你只是想跑help - 把版本号、路径拼接等计算移到
provider { ... }或layout.projectDirectory.file(...)这类惰性 API 上，延迟到执行阶段才求值
插件应用要按需、分层
全局 apply 插件（尤其是用 allprojects 或 subprojects）会让每个模块都经历一遍插件初始化，即使该模块根本不需要它。
- 把
apply plugin: 'com.android.application'严格限制在真正需要的模块里，别放在根build.gradle - 用
plugins { id "xxx" version "y.z" }替代传统apply plugin，前者支持惰性解析，且 Gradle 能更好推断依赖边界 - 对通用逻辑（如统一编译选项、依赖版本），抽成预编译脚本插件（
.gradle.kts），并通过plugins { id("com.example.base") }显式引入，而非靠allprojects广播
