pluginA 配置总在 pluginB 之前执行是因为 plugins 块声明顺序决定 apply 顺序，但跨插件配置需依赖生命周期钩子（如 afterEvaluate）或显式插件依赖（requires），而非简单书写顺序。
为什么 pluginA 的配置总在 pluginB 之前执行？
因为 Gradle 的插件应用顺序默认按 plugins { ... } 块中声明的先后顺序执行，且 apply plugin: 是立即执行的。但「另一个插件应用后执行配置」这个需求，本质不是靠「谁先写谁后写」来控制的，而是靠生命周期钩子和依赖关系——你不能假设 pluginB 已经完全初始化完毕，除非你显式等待它。
用 afterEvaluate 等待目标插件完成配置
这是最常用也最稳妥的方式：pluginB 的扩展（如 android{}、java{}）通常在项目 afterEvaluate 阶段才被完整解析。如果你的插件需要读取或修改这些 DSL，必须挂在这个钩子之后。
-
project.afterEvaluate { ... }是安全边界：此时所有插件已 apply，所有扩展属性已注册，所有默认任务已创建 - 但注意：如果 pluginB 自身也在
afterEvaluate里做关键注册（比如动态加 task），那你得再等一轮——这时要改用project.gradle.projectsEvaluated { ... } - 别在
apply()方法体里直接访问project.extensions.findByType(XXXExtension.class)，大概率返回 null；先检查是否存在，再 wrap 在afterEvaluate里
声明插件依赖：plugins {} 块里的 id 强制顺序
如果你控制两个插件（比如自定义的 com.example.base 和 com.example.feature），可以用插件元数据声明依赖关系，让 Gradle 自动排序：
- 在
feature插件的resources/META-INF/gradle-plugins/com.example.feature.properties中添加：implementation-class=com.example.feature.FeaturePlugin和requires=com.example.base - 这样只要项目写了
plugins { id 'com.example.feature' }，Gradle 就会自动先 applycom.example.base，且确保其apply()执行完毕再进feature的apply() - ⚠️ 注意：这种依赖只对二进制插件有效，脚本插件（
apply from:）不支持requires
在 pluginB 的 extension 上注册回调（高级但精准）
某些官方插件（如 Android Gradle Plugin）会在自己的 Extension 上暴露生命周期回调，比盲目等 afterEvaluate 更精确：
- 例如 AGP 提供
androidComponents { onVariants {...} }，你可以在里面安全访问 variant 信息，而无需关心 android DSL 是否“最终确定” - Java 插件提供
project.java { ... }的 configure 块，内部会延迟到 source sets 准备就绪 - 自己写的插件也可以仿照：在 extension 里暴露
configureWhenReady(Closure)方法，内部用project.afterEvaluate触发，对外隐藏时机细节
真正容易被忽略的是：你以为插件 A「应用了」，其实只是它的 apply() 方法执行完了，但它的 DSL 可能还没被用户填写，或者它的任务可能还没被其他插件注入依赖关系——所有跨插件的配置交互，都得以「状态就绪」为前提，而不是「插件已加载」为前提。
