第一次构建慢是因为Gradle需从零启动JVM、解析脚本、下载依赖、初始化模型，耗时集中于Daemon未启用、配置缓存未开启、本地/构建缓存为空及网络拉取延迟；优化须启用org.gradle.daemon=true、org.gradle.configuration-cache=true、org.gradle.caching=true并配置国内镜像源。
第一次构建慢，是因为 Gradle 还没建立任何缓存、没复用进程、也没预热类加载路径——它得从零开始干完所有事。
Gradle Daemon 没启动或没复用
第一次构建时，gradle 命令会启动一个全新 JVM 进程，加载插件、解析 build.gradle、构建任务图、初始化项目模型……这些操作加起来可能占总耗时 40% 以上。后续构建能复用守护进程（Daemon），跳过初始化阶段，直接进入执行。
- 检查是否启用：
org.gradle.daemon=true必须写在gradle.properties里（项目级或用户级） - CI 环境常见错误：脚本里写了
gradle --stop或pkill -f gradle，每次都是冷启动 - IDEA 中若勾选了 “Run build using Gradle from wrapper” 但禁用了 Daemon，也会失效
配置阶段全量解析 + 无配置缓存
首次构建必须逐行执行所有 build.gradle 脚本，计算依赖关系、注册任务、处理 afterEvaluate 等回调——这个“配置阶段”在中大型项目里常耗时 20～60 秒。而配置缓存（org.gradle.configuration-cache=true）能把这部分结果序列化复用，二次构建降到毫秒级。
- Gradle 7.4+ 才默认支持稳定版配置缓存；旧版本需加
org.gradle.unsafe.configuration-cache=true - Kotlin DSL 项目建议同步开启
org.gradle.configuration-cache-problems=warn，避免插件不兼容导致构建失败 - 一旦启用，
settings.gradle和build.gradle中不能有动态逻辑（如System.getenv()、new Date()）
构建缓存和本地仓库都是空的
第一次构建要下载全部依赖（.gradle/caches/modules-2/files-2.1/）、解压插件、编译注解处理器（kapt）、生成 R 文件、运行 AAPT2……这些输出物在后续构建中只要输入没变，就直接复用。
-
org.gradle.caching=true启用后，compileJava、processResources等任务会校验输入哈希，命中即跳过 - 国内环境务必配镜像源，否则
Downloading gradle-8.10-bin.zip或Downloading kotlin-gradle-plugin就卡住几分钟 - 注意：
clean不清构建缓存（.gradle/build-cache-目录），但会清模块输出（build/），所以clean build仍比首次快得多
真正拖慢首次构建的，从来不是 CPU 或磁盘，而是那些「只做一次却代价很高」的动作：JVM 启动、脚本解析、网络拉取、元数据生成。优化方向很明确——让这些动作尽量只发生一次，并确保它们发生的环境是可控、可复用的。
