Gradle配置阶段调用外部命令（如git、curl）极危险，因其破坏确定性、耗时不确定、依赖环境且导致缓存失效；应改用providers.exec惰性执行，或提前生成build-info.properties文件读取，避免在flavor闭包中重复调用。
Gradle 配置阶段执行外部命令（比如 git、curl、jq 或自定义脚本）是构建变慢和不可靠的常见根源——它不仅拖慢配置速度，还会导致 CI 环境失败、IDE 同步卡顿、缓存失效，甚至让 gradle tasks 命令都变慢。
为什么配置阶段调用外部命令特别危险
Gradle 的配置阶段（configuration phase）是“解析所有 build.gradle 并构建任务图”的过程，它必须在任何 task 执行前完成。这个阶段要求：确定性、快速、无副作用。而外部命令天然违反这三条：
- 执行耗时不确定（
git rev-parse在大仓库里可能几百毫秒，CI 上网络超时更难控） - 结果依赖环境（本地没装
jq？CI 机器路径不同？Git 未初始化？） - 破坏增量构建和缓存（Gradle 无法追踪外部命令的输入/输出，一调就 invalidate 整个配置）
用 lazy 属性 + provider 替代直接执行
把原本写在 android { } 或 tasks.register { } 顶层的命令调用，改成惰性求值。核心是用 providers.exec { } 或 providers.environmentVariable() 封装，只在真正需要时才执行，且 Gradle 能感知其输入输出。
- ❌ 错误写法（配置期立刻执行）：
def commit = "git rev-parse --short HEAD".execute().text.trim() - ✅ 正确写法（延迟到 task 执行或属性读取时）：
def commitProvider = providers.exec { commandLine 'git', 'rev-parse', '--short', 'HEAD' }android { defaultConfig { versionNameSuffix "-${commitProvider.get().outputBytes.asText.get()}" } } - ⚠️ 注意：
commitProvider.get()是触发执行的点，别在ext { }或def顶层直接调；优先用.forUseAtConfigurationTime()标明用途（仅当真需在配置期获取时）
把 Git 信息等常用元数据提前固化到文件
多数场景下，你其实只需要 commit hash、branch name、build time 这类信息——它们在一次构建中是静态的。与其每次配置期去查，不如在 CI 或 pre-commit 阶段生成一个 build-info.properties，然后让 Gradle 读文件。
- CI 中生成（示例）：
echo "git.commit=$(git rev-parse --short HEAD)" > build-info.propertiesecho "build.time=$(date -u +%Y-%m-%dT%H:%M:%SZ)" >> build-info.properties - Gradle 中安全读取：
def info = new Properties()file("build-info.properties").withInputStream { info.load(it) }android.defaultConfig.versionNameSuffix = "-${info['git.commit']}" - 优势：零外部依赖、100% 可缓存、IDE 同步不卡、错误可提前暴露
避免在 productFlavors 或 buildTypes 闭包里做动态计算
很多人会在 productFlavors { internal { ... } external { ... } } 里嵌套调用 sh 或读取环境变量，以为只是“配 flavor”，实际会导致每个 flavor 都触发一遍外部命令——10 个 flavor 就执行 10 次 git，配置时间线性爆炸。
- 正确做法：先算出全局唯一值（如
buildId），再通过resValue或 manifest placeholder 注入到各 flavor - 关键原则：所有跨 flavor 共享的动态值，必须在 flavor 定义**之前**准备好，而不是在每个 flavor 闭包里重复计算
- 检查点：运行
./gradlew --dry-run assembleDebug，看是否出现重复的 “Executing command” 日志
最隐蔽的坑是那些看似无害的 System.getenv() 或 new File(...).exists() ——它们本身不耗时，但一旦被 Gradle 的配置逻辑链式触发多次，就会放大成性能瓶颈。真正的优化不是“怎么更快地调外部命令”，而是“能不能根本不调”。
