afterevaluate 会破坏 gradle 配置缓存，导致多模块项目同步变慢、ci 失去复用能力；其执行顺序不可靠、易引发空指针或属性未初始化异常，且阻碍任务图构建与 ide 识别，应优先使用 dsl 原生配置和 provider 延迟求值。
afterEvaluate 会破坏 Gradle 的配置缓存
Gradle 的配置缓存（Configuration Cache）要求所有项目配置必须在 afterEvaluate 之前完成，且不可变。一旦你在 afterEvaluate 里修改 android、tasks 或 dependencies，整个构建就会自动禁用配置缓存——哪怕只有一处，所有模块都 fallback 到传统配置模式。
后果很直接：大型多模块项目同步时间可能从 2 秒涨到 8 秒以上，CI 构建也会失去复用能力。
- 检查是否命中缓存：构建日志中出现
Configuration cache is disabled或Reusing configuration cache可快速判断 - Android 项目尤其敏感：AGP 7.0+ 默认启用配置缓存，
afterEvaluate是常见禁用原因 - 替代方案优先走 DSL 原生支持，比如
buildTypes.debug.applicationIdSuffix就不该塞进afterEvaluate
多个 afterEvaluate 的执行顺序不可靠
afterEvaluate 不是“按代码顺序执行”，而是按 Project 解析完成的先后顺序触发。如果 A 模块依赖 B 模块，但 B 的 build.gradle 更大、解析更慢，那 A 的 afterEvaluate 可能先于 B 执行——这时你试图读取 B 暴露的 Extension 属性，就会得到 null 或默认值。
- 现象：某些构建环境下正常，换台机器或改个依赖就报
Cannot get property 'xxx' on null object - 根本原因：Project 间没有显式依赖声明时，
afterEvaluate的触发时机是竞态的 - 安全做法：用
project.afterEvaluate { if (it.plugins.hasPlugin('xxx')) { ... } }做存在性兜底，而非盲目假设
它让任务注册和配置变成“两阶段黑盒”
Gradle 推荐“配置即注册”：Task 应该在配置阶段就定义好输入输出、依赖关系和动作逻辑。但把 tasks.register 或 task.dependsOn 塞进 afterEvaluate，会导致：
- Task 图在后期才拼凑，Gradle 无法做有效拓扑排序，容易漏掉隐式依赖
- IDE（如 Android Studio）无法提前感知任务结构，Gradle tool window 里不显示自定义任务
-
--dry-run或./gradlew tasks输出缺失，调试时只能靠猜 - 正确姿势是用
Provider和Property延迟求值，例如：myTask.inputs.property("version").set(project.provider { ext.version })
调试时堆栈完全丢失上下文
当 afterEvaluate 里的闭包抛出异常，错误堆栈只会显示 at build_*.gradle:xx，而不会告诉你这个闭包是被哪个插件、在什么条件下触发的。更糟的是，如果多个插件都注册了 afterEvaluate，你根本分不清哪段逻辑先执行、哪段覆盖了前者的配置。
- 典型报错：
Could not set unknown property 'xxx' for extension 'android' of type com.android.build.gradle.AppExtension - 这往往不是属性名写错，而是
android插件还没完成初始化，你就急着去设它 - 真正该查的是插件 apply 顺序、Extension 创建时机，而不是在
afterEvaluate里加 try-catch
afterEvaluate 当万能胶水，它只是留给极少数跨 Project 协作或动态元数据注入的逃生通道。
