buildConfigField 必须置于productFlavors或buildTypes内才生效，defaultConfig中定义会导致多环境值相同；字符串值需外单内双引号，如'"http://api.dev"'；boolean/int类型也须传字符串如"true"；字段按解析顺序覆盖，建议统一在flavor中定义。
buildConfigField 必须写在 productFlavors 或 buildTypes 里才生效
直接写在 defaultConfig 里虽然能编译通过，但所有环境共用同一套值，起不到区分作用。真正做多环境配置时，必须把 buildConfigField 放进 productFlavors（如 dev、pro）或 buildTypes（如 debug、release）块内。
常见错误现象：改了 dev 的 buildConfigField，但运行 devDebug 时还是拿到 pro 的值——大概率是字段写错位置，或者没触发对应 variant 的构建。
-
productFlavors适合区分「业务环境」（开发/测试/正式），每个 flavor 生成独立的BuildConfig字段 -
buildTypes适合区分「构建行为」（是否混淆、是否打日志），常用来控制DEBUG、LOG_LEVEL这类开关 - 两者叠加后，最终生效的是 flavor + buildType 组合（如
devDebug会优先取devflavor 定义的字段，再被debug覆盖同名字段）
字符串值必须用双引号包裹且外层加单引号
buildConfigField 的第三个参数是字面量字符串，不是 Groovy 表达式。写成 "http://api.dev" 会报错，必须写成 '"http://api.dev"' ——外层单引号是 Groovy 字符串，内层双引号是 Java 字符串的引号。
容易踩的坑：
- 漏掉内层双引号：
buildConfigField "String", "URL", "http://api.dev"→ 编译失败，BuildConfig.URL变成未定义变量 - 用错引号顺序：
"'http://api.dev'"→ Java 代码里变成带单引号的字符串，运行时报Malformed URL - 拼接路径时硬编码 host：
'"https://' + ENV_HOST + '/v1"'→ 不推荐，应统一用gradle.properties预定义，避免敏感信息泄露
boolean 和 int 类型字段不能省略引号
即使值是 true 或 1，也必须作为字符串字面量传入。写成 buildConfigField "boolean", "ENABLE_LOG", true 是错的；正确写法是 buildConfigField "boolean", "ENABLE_LOG", "true"。
原因：Gradle 构建时只是文本替换，BuildConfig.java 文件是静态生成的。如果传布尔字面量，生成的代码会是 public static final boolean ENABLE_LOG = true;，看似没问题，但一旦你用 buildTypes 覆盖该字段（比如 release 设为 "false"），类型不一致会导致编译失败。
- 安全写法统一用字符串：
"true"、"false"、"1"、"0" - Java 侧读取时保持一致：
BuildConfig.ENABLE_LOG.equals("true")或封装成工具方法 - 避免混用类型：不要在一个项目里有的地方用
"true"，有的地方用Boolean.TRUE.toString()
字段名冲突时，后定义的会覆盖前定义的
Gradle 按照解析顺序合并配置：先 defaultConfig，再 productFlavors，最后 buildTypes。如果三处都定义了 API_URL，最终生效的是最靠后的那个。
典型问题场景：
-
defaultConfig定义了buildConfigField "String", "API_URL", '"https://default.com"' -
productFlavors.dev也定义了同名字段 → 生效 -
buildTypes.debug再定义一次 → 覆盖dev的值，devDebug变体实际拿到的是debug里的值
建议只在一个层级定义字段，比如全部收口到 productFlavors，buildTypes 仅用于控制构建行为相关字段（如 IS_DEBUG_BUILD）。否则调试时容易误判来源。
