clean build 是先执行 clean（清空 build 目录）再执行 build（编译、测试、打包），确保从头构建；build 本身不清理旧产物，可能因缓存导致输出不可靠。
clean build 是两步操作，build 是单步但隐含依赖
clean build 不是 Gradle 的一个内置任务，而是你同时执行了两个任务：clean 和 build。Gradle 会先运行 clean（删除 build/ 目录），再按生命周期顺序执行 build（包含编译、测试、打包等）。它本质是「强制从头构建」。
build 本身不自动清理旧产物。如果上次构建失败、中间文件残留（比如部分 class 没重编译、test report 错位、jar 包未更新），build 可能跳过某些 task（状态为 UP-TO-DATE），导致输出不可靠。
常见错误现象：
- 修改了 Java 源码但
build后 class 文件没更新 -
build/libs/下的 jar 包时间戳没变，实际内容却是旧的 - 测试失败后改对了，再跑
build却仍报同样错误（因为 test task 被跳过）
所以不是「要不要 clean」的问题，而是「什么时候必须 clean」：只要怀疑构建缓存干扰结果，就该加 clean。
build -x test 和 clean build 的效果不等价
build -x test 是跳过测试阶段的完整构建流程，它仍会执行 compileJava、processResources、jar 等，只是不跑 test task。但它不会清空 build/，也不会影响已存在的 build/reports/test 或 build/test-results。
clean build 则彻底抹掉所有构建中间态，无论是否被标记为 UP-TO-DATE，全部重建。
关键区别在于：
-
-x test控制「执行哪些 task」 -
clean控制「是否复用上一次的输出目录」
如果你只想跳过测试加快构建，用 ./gradlew build -x test；
如果你要确保输出干净可发布（比如 CI 打包、发版前验证），必须用 ./gradlew clean build。
assemble 和 build 在 Android / Java 项目里行为不同
在纯 Java 项目中，assemble 只打包（生成 jar），不编译测试、不跑 check；build = assemble + check（含 test）。
但在 Android 项目里，build 默认会生成 debug 和 release 两种 APK，而 assemble 不会自动触发 test，但会生成所有 variant 的包（assembleDebug、assembleRelease 等才是更常用的具体任务）。
容易踩的坑：
- 直接跑
./gradlew build在 Android 项目里可能卡在 lint 或单元测试上，而你其实只想要一个 release APK -
./gradlew assembleRelease更轻量，但不会校验代码质量（无 lint、无 test） - 如果你没配置 signingConfigs，
assembleRelease会失败并提示Keystore was not configured，而build也会失败，但错误信息更分散
clean 并不总是“安全”，尤其在多模块项目中
clean 删除的是当前项目的 build/ 目录。但在多模块结构（如 :app、:lib、:common）中：
-
./gradlew clean（在根目录运行）会清理所有子模块的build/ -
./gradlew :app:clean只清理app模块 - 但如果你只 clean 了
:app，而:lib的 class 文件没更新，app编译时仍会用旧的lib输出，造成 NoSuchMethodError 类错误
另外，clean 会清除 Gradle 的构建缓存（如果启用）、configuration cache（如果开启）、以及本地 .gradle 下的 task 输出缓存 —— 这些在团队协作或 CI 中可能影响构建速度。
真正需要关注的，不是「clean 有没有用」，而是「clean 的作用范围是否匹配你的构建目标」。比如调试某个子模块时，只 clean 它自己；发版前做全量验证，才 clean 根项目。
