Gradle默认跳过已缓存/已成功执行的任务，因启用增量构建和UP-TO-DATE检查；强制重跑需用--rerun-tasks，它忽略所有状态直接执行，但前提是Task已注册进执行图，否则需先通过create、dependsOn或configure显式加入。
Gradle 默认跳过已缓存/已成功执行过的任务，想强制重跑，不能只靠 ./gradlew taskName —— 它不会重新执行，除非你明确打破增量构建或绕过 up-to-date 检查。
为什么 ./gradlew myTask 不会强制重执行
因为 Gradle 的 Task 执行分两阶段：配置阶段（读脚本、建图）和执行阶段（真正干活）。但更重要的是，大多数内置 Task（如 compileJava、test）默认启用增量构建（incremental build）和 up-to-date 检查：只要输入没变、输出存在且时间戳未被破坏，Gradle 就直接标记为 UP-TO-DATE 并跳过执行。
常见现象：
- 改了
doLast里的日志，再跑./gradlew myTask，控制台仍显示UP-TO-DATE - 手动删了
build/下某目录，但任务还是跳过 —— 因为 Gradle 记录的“输出路径”可能不是你删的那个 - 用
tasks.register定义的任务，即使加了doLast，也没触发 —— 它根本没被加入执行图，更谈不上“是否重执行”
--rerun-tasks 是最直接的强制重执行方式
这个命令行选项会忽略所有 up-to-date 状态，让每个匹配任务无条件进入执行阶段。它不改变任务逻辑，也不清缓存，只是“假装什么都没发生过”。
使用场景：
- 调试自定义 Task 行为（比如验证
doFirst/doLast执行顺序） - 临时绕过编译/测试缓存，确认是否真有副作用（如生成文件、发 HTTP 请求）
- CI 环境中避免因本地缓存导致行为不一致
示例：
./gradlew build --rerun-tasks
注意：--rerun-tasks 对所有参与构建的任务生效，包括依赖项。如果只想重跑某一个，确保它没被其他任务隐式跳过（见下一条）。
自定义 Task 必须显式加入执行图，否则 --rerun-tasks 也无效
很多人写完 tasks.register('myCheck') { doLast { println 'check!' } }，然后跑 ./gradlew myCheck --rerun-tasks，结果报错：Task 'myCheck' not found —— 因为 register 是延迟创建，没被任何路径引用或依赖链触发，它压根不存在于执行图里。
正确做法（任选其一）：
- 改用
tasks.create('myCheck')：立即创建并注册到tasks容器，可直接调用 - 加依赖：比如
classes.dependsOn myCheck，这样执行./gradlew build时它会被拉入图中 - 手动绑定到生命周期：如
check.dependsOn myCheck，之后跑./gradlew check --rerun-tasks就能触发它
另外，如果你用的是 Kotlin DSL，register 后必须显式调用 .configure { ... } 或通过 tasks.named(...) 获取后配置，否则闭包里的 doLast 可能根本没注册上。
--no-build-cache 和 clean 是辅助手段，不是替代方案
--no-build-cache 只禁用远程/本地构建缓存（Build Cache），不影响单个 Task 的 up-to-date 检查；clean 删除 build/ 目录，对某些 Task（如 processResources）有效，但对无输出路径的纯逻辑 Task（比如只打印日志）完全没用。
真正关键的判断点是：
- 这个 Task 是否声明了
inputs和outputs？没有的话，Gradle 默认认为它“总是过期”，--rerun-tasks反而显得多余 - 你是否在
doLast里做了不可见副作用（比如写临时文件、调外部 API）？这类 Task 应该显式声明outputs.upToDateWhen { false }，而不是依赖命令行开关 - 你用的是 Groovy 还是 Kotlin DSL？Kotlin 中
register返回的是TaskProvider，必须用.configure或.get()才能访问实例，直接链式调doLast会静默失败
强制重执行不是补丁，而是暴露配置缺陷的信号。最稳妥的做法，永远是让 Task 自身语义清晰：该声明输入就声明，该标记输出就标记，该进执行图就进执行图 —— 剩下的，交给 --rerun-tasks 去兜底。
