Gradle仓库声明的集中管理方式及各配置对解析的影响咨询

各仓库声明方式的适用场景 #

1. allprojects{} / subprojects{}（官方不推荐） #

这是Gradle旧版本的跨模块仓库配置方式，会让所有项目/子项目强制继承同一套仓库列表，灵活性极低。现在仅适合老旧项目的临时过渡，或者所有子项目完全依赖同一批仓库的极端场景——官方明确推荐用dependencyResolutionManagement替代它。

2. dependencyResolutionManagement{}（推荐用于依赖仓库） #

这是Gradle 6.0+推出的集中管理项目依赖仓库的标准方式，配置在settings.gradle.kts中。所有模块的依赖（第三方库、内部模块依赖）都会使用这里声明的仓库解析，能彻底避免每个模块重复写仓库配置，是多模块项目统一管控依赖源的首选方案。

3. pluginManagement{}（插件专属仓库） #

专门用于Gradle插件的下载，和依赖仓库是完全独立的体系。因为插件的解析发生在项目构建的最早阶段（settings阶段），早于依赖解析。适合配置插件专属仓库，比如Gradle官方插件门户、企业内部的插件仓库，确保构建所需的插件能被正确拉取。

4. buildscript{}（旧版构建脚本依赖） #

这是Gradle 6.0之前管理构建脚本自身依赖的方式，比如用classpath引入旧版插件、自定义构建逻辑的依赖。现在大部分场景已被pluginManagement替代，但如果项目里还保留着老的插件声明方式（比如无法迁移的 legacy 插件），就需要在buildscript里配置仓库，用于下载这些构建脚本级别的依赖。

是否需要同时使用多种方式？ #

是的，这是多模块项目的常见情况：

• 通常会同时用pluginManagement管理插件仓库、dependencyResolutionManagement管理依赖仓库，两者各司其职，互不干扰。
• 如果项目存在遗留的buildscript块（比如某些老插件只能通过classpath引入），就需要同时保留buildscript的仓库配置，直到完成插件声明方式的迁移。

dependencyResolutionManagement与pluginManagement的仓库关系 #

两者是完全独立的仓库集合，不存在合并、覆盖或冲突：

• pluginManagement的仓库仅负责下载Gradle插件，在settings阶段就执行解析，和后续的依赖解析流程完全分开。
• dependencyResolutionManagement的仓库负责项目所有业务依赖、库依赖的解析，在项目构建阶段执行。
• 比如你可以在pluginManagement里配置企业内部插件仓库，在dependencyResolutionManagement里配置Maven Central和内部依赖仓库，两者不会互相影响。

内容的提问来源于stack exchange，提问作者Daniel Schröder