--no-build-cache 参数临时禁用构建缓存，仅本次生效，不修改配置、不清理已有缓存，用于调试缓存污染或“outputs not up-to-date”问题；clean 命令无法绕过缓存，必须显式添加该参数才能强制全量重执行。
用 --no-build-cache 参数临时跳过构建缓存
构建缓存（org.gradle.caching=true）默认启用后，Gradle 会复用之前任务的输出结果。但调试时若想确认某次构建是否真被缓存“污染”，或排查 Task outputs were not up-to-date 类错误，必须绕过缓存强制重跑——最直接的方式就是加 --no-build-cache。
它只影响本次命令，不修改任何配置文件，也不影响后续构建，是安全、可逆的调试手段。
- 在项目根目录运行：
./gradlew build --no-build-cache - 若同时想禁用配置缓存（避免脚本兼容性干扰），补上：
--no-configuration-cache - 注意：该参数不会清除已存在的缓存内容，只是让本次构建不读也不写缓存
clean 命令本身不等于禁用构建缓存
很多人误以为 ./gradlew clean 后再 build 就自动跳过了构建缓存，其实不是。clean 只删 build/ 目录，不影响 .gradle/caches/ 下的任务输出缓存。下一次 build 仍可能命中缓存，导致“明明 clean 了却没重编译”的现象。
真正要验证任务是否从头执行，必须显式带上 --no-build-cache，否则 Gradle 仍会尝试复用远程或本地缓存中的 task output。
-
./gradlew clean build→ 仍可能命中缓存 -
./gradlew clean build --no-build-cache→ 强制全量重执行 - CI 脚本中慎用此参数，会丢失团队级缓存收益
为什么不用改 gradle.properties？
临时禁用 ≠ 永久关闭。修改 gradle.properties 中的 org.gradle.caching=false 会影响所有后续本地构建，还可能误提交到 Git，污染团队环境。尤其在多人协作项目中，这种硬编码式关闭容易引发构建行为不一致。
命令行参数优先级高于配置文件，所以 --no-build-cache 是唯一推荐的临时方案。
- 它不改动任何文件，不需权限，不依赖 IDE 状态
- 和
--rerun-tasks不同：后者强制重跑但依然会写入缓存；--no-build-cache则彻底隔离缓存读写 - 搭配
--scan使用，可在 Gradle Build Scan 中清晰看到 “Build cache: disabled” 标识
容易忽略的副作用：远程缓存 push 也会被跳过
如果你的项目启用了远程构建缓存（如 Gradle Enterprise 或自建 Artifactory），--no-build-cache 不仅跳过读取，也禁止本次构建结果上传到远程。这意味着：即使这次构建成功且稳定，其他协作者也无法受益于它的输出。
这在 CI 流水线中尤为关键——日常调试可以关，但 PR 构建或 nightly build 必须确保缓存可用，否则会放大构建耗时波动。
- CI 脚本中应避免无条件加
--no-build-cache - 本地调试时，建议配合
--no-daemon避免守护进程残留状态干扰 - 若需长期禁用（如某些插件不兼容），应在
gradle.properties中设为false，而非靠命令行掩盖问题
