Gradle 8 Kotlin DSL中，约定插件应放buildSrc还是build-convention？

先明确两种方式的核心区别：

• buildSrc：Gradle自带的特殊目录，无需额外配置就会被识别为构建逻辑子项目，编译后自动加入项目类路径。
• build-convention：手动创建的独立子项目，需要在settings.gradle.kts中声明它是项目的一部分，编译逻辑和普通业务子项目一致。

各自的优劣势对比 #

buildSrc：简单但局限明显 #

• 优势：
  • 零额外配置，Gradle自动处理，适合快速搭建简单的构建规则。
  • 写好的插件可直接在主项目的构建文件中引用，无需添加依赖声明。
• 局限：
  • 缓存效率低：buildSrc的编译产物默认不参与Gradle远程缓存，修改代码后会触发全量重新编译，大型项目中会显著拖慢构建速度。
  • 复用性差：只能在当前项目内使用，无法打包发布给其他项目共享构建逻辑。
  • 依赖易冲突：buildSrc的依赖会全局影响整个构建流程，容易引发依赖版本冲突问题。

build-convention：灵活适配复杂场景 #

• 优势：
  • 缓存友好：作为普通子项目，其编译产物可参与本地/远程缓存，修改后仅需增量编译，大幅提升大型项目的构建效率。
  • 复用性强：可以打包成独立构件发布到私有仓库，供多个项目引用共享统一的构建规则。
  • 依赖隔离清晰：build-convention的依赖仅作用于自身子项目，不会污染主项目的依赖环境，降低冲突风险。
  • 结构灵活：可拆分多个子模块（例如分别管理Java、Kotlin、Android的约定插件），构建逻辑模块化更清晰。
• 局限：
  • 配置稍繁琐：需要在settings.gradle.kts中声明子项目，主项目引用插件时还需添加依赖配置。

合理选择的依据 #

1. 项目规模与复杂度：
   • 小型项目/简单构建逻辑：用buildSrc足够，配置简单省心。
   • 中大型项目/复杂构建逻辑：优先选build-convention，模块化、缓存和复用性的优势能显著降低维护成本。
2. 构建逻辑的复用需求：
   • 仅当前项目使用：两种方式均可，buildSrc更便捷。
   • 需要跨多个项目共享：必须使用build-convention，支持打包发布。
3. 构建性能要求：
   • 对构建速度敏感的大型项目：build-convention的缓存机制能有效减少重复编译时间。

Gradle官方导向 #

Gradle官方文档中，buildSrc作为入门示例展示基础用法，而build-convention是官方推荐的进阶构建逻辑管理方案——尤其是在需要共享构建规则、优化构建性能的场景下，官方更倾向于后者。

内容的提问来源于stack exchange，提问作者tribbloid