Gradle任务配置规避：findByPath替代方案及project解析疑问

直接调用project('foo').tasks.named('bar')确实会触发foo子项目的提前解析，破坏配置规避（Configuration Avoidance）的效果——因为project('foo')会强制Gradle立即加载该子项目的配置逻辑，违背了“仅在必要时解析配置”的原则。

下面是两种安全可行的替代方案，核心都是延迟子项目与任务的解析操作：

1. 直接用tasks.named()传入完整任务路径 #

Gradle的tasks.named()方法支持直接传入带项目路径的完整任务名，它会返回一个Provider<Task>对象，直到任务实际需要配置或执行时才会去查找对应的任务，完全符合配置规避的要求。

Groovy DSL示例： #

myTask.dependsOn(tasks.named(':foo:bar'))

Kotlin DSL示例： #

myTask.dependsOn(tasks.named(":foo:bar"))

这种写法是Gradle官方推荐的最优方案，代码简洁且性能最佳，不需要提前解析任何子项目。

2. 用project.provider()延迟子项目解析 #

如果需要更复杂的动态逻辑，可以用project.provider()包装子项目的任务查找操作，确保只有在依赖被实际计算时才触发子项目解析：

Groovy DSL示例： #

myTask.dependsOn(project.provider {
    project(':foo').tasks.named('bar').get()
})

Kotlin DSL示例： #

myTask.dependsOn(project.provider {
    project(":foo").tasks.named("bar").get()
})

这里的闭包代码会被延迟执行，直到Gradle需要确定myTask的依赖关系时才会解析foo子项目并查找任务，不会影响配置规避的效果。

注意事项 #

• 绝对不要直接调用project(':foo')或tasks.findByPath()，这类操作会触发立即解析，完全破坏配置规避的优化。
• 优先选择第一种方案，它是Gradle为配置规避场景专门设计的简化写法，比第二种更高效。

内容的提问来源于stack exchange，提问作者Kelvin Chung