任务未声明inputs/outputs会导致gradle无法增量构建，必须显式配置inputs.files、outputs.dir等；检查方法是运行./gradlew tasks --all看是否有up-to-date标识，并确认build.gradle中路径是否用layout.projectdirectory或provider api正确声明。
怎么看任务有没有声明 inputs/outputs
Gradle 增量构建的前提是任务必须显式声明输入和输出，否则 Gradle 默认把它当作「始终需要执行」的黑盒任务。很多自定义 Task 看似逻辑完整，但没加 inputs 或 outputs，结果每次运行都全量执行——不是 Gradle 失效，是它根本没机会判断是否跳过。
检查方法很简单：在终端运行 ./gradlew tasks --all，找到你的任务名，看描述里是否含「UP-TO-DATE」字样。如果没有，大概率没声明；再打开 build.gradle，搜索该任务定义，确认是否包含类似 inputs.dir、outputs.file 这类调用。
- 常见漏写点：
doLast里有文件读写，但没把对应路径设为inputs.files或outputs.dir - 路径写错：比如用
file("src/main/res")而非file("$project.projectDir/src/main/res")，导致路径解析为空，Gradle 认为「无输入」 - 动态路径未延迟求值：直接赋值字符串（如
inputs.dir "build/tmp/mytask"），而非用inputs.dir layout.buildDirectory.dir("tmp/mytask")，后者能随构建生命周期正确解析
为什么 inputs.files 没生效，却还是每次都执行
最常踩的坑是把「文件内容」和「文件存在性」混为一谈。Gradle 默认只对 inputs.files 做内容哈希快照，但如果你传入的是一个空目录、一个不存在的路径、或一个被 clean 清掉但没重新创建的路径，inputs.files 会返回空集合——Gradle 就认为「这次没输入」，于是判定输入变更，强制重跑。
验证方式：加 -i 参数运行任务，观察日志里是否有类似 Input file collection is empty 的提示。
- 修复建议：用
inputs.files(layout.projectDirectory.file("xxx"))替代硬编码字符串路径 - 若依赖上游任务输出，别用
file("build/xxx")，改用inputs.files(tasks.named("xxxTask").flatMap { it.outputs.files })，确保依赖链可追踪 - 避免在
configure块里直接操作inputs，Gradle 8.4+ 对配置阶段的访问更严格，应统一用Property或ProviderAPI
outputs.upToDateWhen 和 outputs.cacheIf 有什么区别
outputs.upToDateWhen 是「我来决定是否跳过」，属于任务级守门员；outputs.cacheIf 是「我允许结果被缓存」，影响的是构建缓存（Build Cache）能否复用。二者不互斥，但作用域完全不同。
典型误用：用 upToDateWhen { false } 强制重跑，以为能绕过增量逻辑——其实只是让 Gradle 放弃当前构建会话的 UP-TO-DATE 判断，不影响缓存；而 cacheIf { false } 会让该任务结果永远不进缓存，但单次构建仍可能因输入未变而跳过。
-
upToDateWhen适合临时调试，比如你想确认某段逻辑是否真被跳过，可先设为{ false }强制执行一次，再改回默认逻辑 -
cacheIf应谨慎使用：例如任务输出含时间戳或随机 ID，就必须cacheIf { false }，否则缓存结果会污染后续构建 - 注意：Gradle 8.4+ 要求
upToDateWhen的闭包必须是纯函数（无副作用），否则可能被静默忽略
怎么用 -i 日志定位具体哪项输入变了
运行 ./gradlew myTask -i 后，关键线索藏在类似这样的日志行里：
Task ':myTask' is not up-to-date because: Input file <path> has changed. Output file <path> does not exist.</path></path>
如果只看到「Input files have changed」但没列具体文件，说明 Gradle 没法精确归因——通常是输入声明用了模糊集合（如 fileTree(dir: "src", include: "**/*.txt")），而其中某个文件的修改时间被外部工具（如 IDE 自动保存、Git checkout）意外更新了。
- 建议搭配
--no-daemon -Dorg.gradle.internal.http.connectionTimeout=10000排除守护进程干扰 - 对可疑输入路径，手动执行
find src/ -name "*.txt" -ls | head -5查看最近修改时间，比对日志里的变更时间戳 - 若用 Kotlin DSL，注意
inputs.files(project.layout.projectDirectory.dir("src").asFileTree)比fileTree("src")更稳定，前者受 Gradle 生命周期管理
-i 看日志里那句「because」后面到底写了什么。
