--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，而非靠命令行掩盖问题