Gradle插件无法在配置阶段直接配置其他插件用tasks.register()延迟注册的任务，如compileJava；应使用tasks.withType(JavaCompile).configureEach{}或tasks.named("xxx", Type){}安全配置。
Gradle插件无法直接“配置”其他插件注册的任务，除非那个任务在配置阶段已存在、且未被标记为 configure 保护或延迟执行。关键不在“怎么配”，而在于“什么时候能配”——绝大多数官方插件（如 java、application）注册的任务都是延迟注册（tasks.register()），它们在配置阶段根本还不存在。
为什么 tasks.named() 找不到其他插件的任务
常见现象是：你在自定义插件里写 tasks.named("compileJava")，却抛出 UnknownTaskException。这不是路径错、名字错，而是时机问题——compileJava 是 java 插件用 tasks.register("compileJava", JavaCompile) 注册的，它只在构建执行阶段前才真正实例化，配置阶段查无此任务。
- 核心判断依据：看目标插件是否使用
tasks.register()（现代方式）还是旧式task块（立即创建） -
tasks.named("xxx")只能访问已注册（但未必已配置）的任务；tasks.withType(JavaCompile)更可靠，因为它按类型匹配，不依赖名称 - 如果目标插件文档没说明任务注册时机，就默认它是延迟注册——别硬查名字
如何安全地配置 compileJava 这类任务
正确做法不是“等它出现再配”，而是用 Gradle 提供的生命周期钩子，在它注册后立刻介入。最常用的是 tasks.withType() + configureEach 或 register 回调：
tasks.withType(JavaCompile).configureEach {
options.encoding = "UTF-8"
// 注意：这里修改的是所有 JavaCompile 类型任务，包括 compileTestJava
}
// 或者更精准地指定名称（仅当确定它已注册）
tasks.named("compileJava", JavaCompile) {
options.fork = true
}
-
configureEach是推荐方式：它会自动监听后续注册的同类型任务，无需关心注册顺序 -
named(name, type)要求任务已注册且类型匹配，适合你明确知道插件行为（如 Android Gradle Plugin 的android.applicationVariants.all） - 避免在
afterEvaluate里反复查tasks.findByName()，这属于反模式，容易漏配或重复配置
自定义插件中依赖其他插件任务的典型场景
比如你想让自己的 generateDocs 任务必须在 classes 之后运行，但 classes 是 java 插件注册的延迟任务：
- 不能写
dependsOn tasks.getByName("classes")—— 配置阶段报错 - 应改用
dependsOn tasks.named("classes")，Gradle 会自动延迟解析该依赖 - 若需在
generateDocs中读取classes输出路径，要用classes.map { it.outputs.files }这类 Provider API，而不是直接访问classes.outputs.files - 跨插件通信时，优先通过
project.extensions暴露配置，而非硬绑任务实例
真正容易被忽略的点是：你以为在配任务，其实是在和 Gradle 的配置/执行两阶段模型打交道。任务名只是个标识，背后是 Provider、TaskConfigurationAvoidance、TaskDependency 这套机制在起作用。不理解这个分层，光记语法只会反复踩坑。
