clean 会彻底关闭增量构建，导致所有任务重新执行，拖慢构建速度；它删除 build/ 目录使 Gradle 失去输入比对依据，迫使全量构建，耗时为增量构建的 3–10 倍。
执行 clean 会彻底关闭增量构建，让所有任务重新执行，这是它拖慢构建速度的根本原因。
为什么 clean 会让下一次构建变慢
Gradle 的快，依赖于「输入没变 → 跳过任务」的判断逻辑。clean 把 build/ 目录整个删掉，等于把所有任务的输出文件、时间戳、缓存哈希全清空。下次 build 时，Gradle 看不到任何上一次的产出，只能从头编译、打包、转换、dex 化……哪怕你只改了一行 Java 代码。
-
clean后首次构建 ≈ 全量构建（clean build），耗时通常是增量构建的 3–10 倍 - Android 项目中，
clean会触发compileDebugJavaWithJavac、mergeDebugResources、transformDexArchiveWithDexMergerForDebug等大量重量级任务重跑 - 即使启用了
org.gradle.caching=true，构建缓存也只复用「已执行过的任务输出」；而clean后首次构建没有历史缓存可复用，远程缓存命中率也会归零
clean 真的必要吗？什么场景下才该用
绝大多数日常开发中，clean 不是必须步骤，反而是性能杀手。它只在以下明确问题存在时才值得触发：
- 资源 ID 冲突或 R.java 生成异常（比如 AAR 引入了同名资源）
- 修改了
build.gradle中影响任务输入的配置（如sourceSets、manifestPlaceholders、resValue） - 升级了 AGP 或 Kotlin 插件版本，且文档明确提示需 clean（例如某些 kapt 输出路径变更）
- CI 流水线中为保证环境干净，配合
--no-daemon使用
注意：Build → Clean Project 在 Android Studio UI 里点一下，背后就是 ./gradlew clean，效果完全一致。
替代 clean 的轻量方案
遇到疑似缓存污染但又不想全量重建？优先试这些更精准的操作：
- 只清理特定模块：运行
./gradlew :app:clean，而非根项目的clean - 跳过部分任务：加
--rerun-tasks强制重跑可疑任务，但保留其他 up-to-date 判断 - 手动删子目录：比如只删
app/build/intermediates/javac/，保留app/build/caches/和.gradle/下的构建缓存 - 用
./gradlew --stop关闭守护进程再重试，有时比clean更快恢复一致性
真正卡顿的从来不是 clean 命令本身，而是它暴露了项目里那些本不该频繁触发 clean 的深层问题：比如动态版本号导致依赖解析不稳定、自定义 Transform 没声明输入输出、kapt 任务未启用增量模式。这些才是构建慢的根因，clean 只是那个按下确认键的人。
