buildsrc是解决多模块gradle项目重复、分散、易错构建逻辑的必需方案：通过集中定义版本号、自定义任务和插件约定，实现跨模块复用与统一管理，提升类型安全、ide支持及维护效率。
当你在多模块项目里反复改十几个 build.gradle.kts 文件里的相同版本号、插件配置或任务逻辑时，buildSrc 就该上了——它不是“可选优化”，而是重复、分散、易错构建逻辑的止损点。
多个子模块共用同一套依赖版本号
比如 app、feature-login、core-network 都要声明 retrofit 和 kotlinx-coroutines，且版本必须严格一致。手动维护容易漏改一处，导致运行时 NoClassDefFoundError 或 IncompatibleClassChangeError。
- 在
buildSrc/src/main/kotlin/Versions.kt里定义object Versions { val retrofit = "2.9.0" } - 各模块直接写
implementation("com.squareup.retrofit2:retrofit:${Versions.retrofit}") - 升级时只改
Versions.kt一行，所有模块自动同步，IDE 还能跳转、补全、类型检查
需要自定义 Gradle 任务且跨模块复用
例如你写了生成 API 文档的 generateApiSpec 任务，或者校验资源命名规范的 checkResourceNaming，但不想在每个模块都 copy-paste 一整段 tasks.register 块。
-
buildSrc里用 Kotlin 写一个class GenerateApiSpecTask，继承DefaultTask - 再封装成扩展函数：
fun Project.apiSpec() { tasks.register<generateapispectask>("generateApiSpec") { ... } }</generateapispectask> - 任意模块只需调用
apiSpec()，无需重复定义逻辑，也不用apply from引入脚本
想给子模块统一应用插件并预设配置
比如所有 Android 模块都要启用 androidx.navigation + hilt，且每处都要配 compileOptions、kotlinOptions、composeOptions。这些不是“开箱即用”的插件行为，而是团队内部约定。
- 在
buildSrc里写一个ConventionsPlugin，apply时自动plugins.apply("com.android.library")并设置好sourceCompatibility等 - 子模块只需
plugins { id("my.company.conventions") }，不用再记一堆样板配置 - 注意：不能在
buildSrc里 apply 其他插件的pluginManagement块，那是settings.gradle.kts的职责
真正容易被忽略的是 buildSrc 的作用域边界：它只对当前项目生效，无法跨 Git 仓库共享；如果多个独立项目要用同一套构建逻辑，得做成发布到 Maven 仓库的独立插件，而不是堆砌 buildSrc。另外，buildSrc 修改后首次构建会触发编译，别误以为是卡死——这是正常行为。
