依赖解析拖慢构建是因为它需校验传递路径、解决版本冲突、比对缓存哈希、访问远程元数据、执行约束规则及推导可选依赖，模块多或含动态版本时该阶段可占总耗时30%以上。
为什么依赖解析会拖慢整个构建
依赖解析不是“下载完就完事”的简单动作。Gradle 在执行 resolve 时要做的事包括：校验传递路径、检查版本冲突、比对本地缓存哈希、访问远程仓库元数据（哪怕你本地有 jar）、触发依赖约束规则（如 platform 或 constraints），甚至还要为每个 implementation 动态推导可选依赖。一旦项目模块多、依赖树深，或用了大量动态版本（1.2.+、latest.release），这个阶段很容易占到总耗时的 30% 以上。
禁用动态版本和快照依赖
动态版本是依赖解析最典型的性能杀手。每次构建，Gradle 都会强制向远程仓库发起 HEAD 请求，检查是否有更新；快照版本（-SNAPSHOT）则会额外触发时间戳比对和元数据刷新。
- 把所有
1.4.+、2.+、latest.integration全部替换成固定版本，比如1.4.3 - 开发阶段如需快速迭代，改用
project(':lib-core')这类项目依赖，而非发布快照到 Nexus - 用
dependencyUpdates插件定期扫描过期依赖，而不是靠动态版本“自动升级” - 在
gradle.properties中加org.gradle.dependency.verification=true并配好verification-metadata.xml，避免重复校验
调整仓库顺序 + 关闭不必要的仓库
Gradle 按 repositories 声明顺序逐个查找依赖，只要前面的仓库返回了“找不到”，它就会继续查下一个；但如果某个仓库响应极慢（比如网络抖动、私服挂了），整个解析就会卡住。
- 把最可能命中依赖的仓库放最前面：例如公司私有 Maven 仓 → JCenter（已停用，务必删掉）→ Maven Central
- 确认没有残留
maven { url "https://jcenter.bintray.com" }—— JCenter 已下线，Gradle 会超时后才跳过，单次浪费 3–5 秒 - 子模块中不要重复声明仓库，统一收口到根项目的
settings.gradle.kts的dependencyResolutionManagement块里 - CI 环境可加
--offline强制走本地缓存，但前提是本地缓存已预热（比如通过./gradlew dependencies --dry-run提前拉取）
启用依赖锁定（Dependency Locking）
锁定文件（gradle.lockfile）能让 Gradle 跳过版本解析逻辑，直接按锁定结果复用已知坐标和校验值，尤其适合 CI 和多环境一致构建。
- 在
gradle.properties开启：org.gradle.configuration-cache=true（配置缓存需配合锁定才能稳定生效） - 首次生成锁文件：
./gradlew dependencies --write-locks - 后续构建默认读取锁文件；若要更新某依赖，运行
./gradlew dependencies --update-locks 'com.example:lib' - 注意：Kotlin DSL 项目需确保
enableFeaturePreview("VERSION_CATALOGS")已启用，否则锁文件可能不被识别
真正卡住构建的往往不是“没下完”，而是反复试探、验证、回退。依赖解析优化的核心，是把不确定性变成确定性——版本号写死、仓库路径收窄、校验过程固化。做完这三步，再跑一次 ./gradlew build --scan，你会明显看到 “Resolving dependencies” 阶段从红色高亮变成浅灰，这才是有效优化的信号。
