如何避免多模块Android项目重复定义productFlavors与buildConfigField？

我有一个包含以下模块的多模块Android项目：

• app（应用模块）
• data（Android库模块）
• domain（纯Kotlin模块）

我通过productFlavors（dev、staging、prod）定义BASE_URL这类环境专属值，示例代码位于data/build.gradle.kts：

flavorDimensions += "env"

productFlavors {
    create("dev") {
        dimension = "env"
        buildConfigField(
            "String",
            "BASE_URL",
            "\"https://api.dev.example.com/graphql/\""
        )
    }
    create("staging") {
        dimension = "env"
        buildConfigField(
            "String",
            "BASE_URL",
            "\"https://api.staging.example.com/graphql/\""
        )
    }
    create("prod") {
        dimension = "env"
        buildConfigField(
            "String",
            "BASE_URL",
            "\"https://api.example.com/graphql/\""
        )
    }
}

由于以下原因，我必须在app模块中定义完全相同的flavor结构（相同名称、相同维度）：

• 每个Android模块都会生成独立的BuildConfig
• data模块直接使用BuildConfig.BASE_URL进行网络请求

这种方式能正常工作，但会导致模块间的flavor定义重复。我想了解：
在Android/Gradle中，是否存在推荐或官方支持的方式来实现：

• 仅定义一次productFlavors
• 在多个Android模块间共享
• 仍保留编译时安全性（BuildConfig）
• 避免脆弱或过于复杂的Gradle逻辑

另外，在多模块Android项目中，是否每个模块单独定义productFlavors是预期且推荐的做法，还是存在更简洁的官方支持方案来避免这种重复？

官方推荐的共享方案：Gradle约定插件（Convention Plugins） #

这是Android官方推荐的多模块配置共享方案，能实现只定义一次Flavor规则，在所有需要的模块中复用，同时保留编译时安全性。

实现步骤： #

1. 创建约定插件模块：在项目根目录下新建build-logic模块（命名可自定义），用于存放共享的Gradle配置逻辑。
2. 定义统一的Flavor配置逻辑：在build-logic/src/main/kotlin下创建一个类似AndroidCommonFlavors.kt的文件，为应用模块和库模块分别编写扩展方法（因为两者的Gradle扩展类型不同）：

import com.android.build.api.dsl.ApplicationExtension
import com.android.build.api.dsl.LibraryExtension

fun ApplicationExtension.configureCommonFlavors() {
    flavorDimensions += "env"
    productFlavors {
        create("dev") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.dev.example.com/graphql/\""
            )
        }
        create("staging") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.staging.example.com/graphql/\""
            )
        }
        create("prod") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.example.com/graphql/\""
            )
        }
    }
}

fun LibraryExtension.configureCommonFlavors() {
    flavorDimensions += "env"
    productFlavors {
        create("dev") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.dev.example.com/graphql/\""
            )
        }
        create("staging") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.staging.example.com/graphql/\""
            )
        }
        create("prod") {
            dimension = "env"
            buildConfigField(
                "String",
                "BASE_URL",
                "\"https://api.example.com/graphql/\""
            )
        }
    }
}

3. 在目标模块中应用约定插件：
   • 在app/build.gradle.kts中：

   plugins {
       id("com.android.application")
       // 应用自定义的约定插件（需先在build-logic中配置插件id）
       id("your.project.android-common-flavors")
   }
   
   android {
       configureCommonFlavors()
       // 模块专属配置写在这里
   }
   

   • 在data/build.gradle.kts中：

   plugins {
       id("com.android.library")
       id("your.project.android-common-flavors")
   }
   
   android {
       configureCommonFlavors()
       // 模块专属配置写在这里
   }
   

这种方式的核心优势：

• 配置只写一次，所有模块复用，彻底消除重复代码
• 保留编译时自动生成BuildConfig的机制，不损失类型安全
• 配置逻辑集中管理，修改时只需改动一处，维护成本大幅降低

关于“每个模块单独定义Flavor是否是预期做法” #

早期多模块Android项目中确实普遍采用单独定义Flavor的方式，但官方目前更推荐使用约定插件来统一配置，减少重复和维护风险。单独定义的方式虽然可行，但存在明显弊端：如果需要新增、修改或删除Flavor，必须在所有相关模块中同步操作，容易出现遗漏或不一致的问题。

不过约定插件也支持灵活扩展——如果某模块有特殊的Flavor需求（比如额外的维度、专属字段），可以在模块的build.gradle.kts中，在调用configureCommonFlavors()之后补充自定义配置，不会限制模块的个性化需求。

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