resValue 必须定义在具体 buildType 块内（如 debug、release）才生效，仅对当前构建变体有效；跨模块不自动传递，类型名须小写（如 "string"），图标和包名需用 src/debug/res/ 和 applicationIdSuffix 配置。
buildTypes 里直接配 resValue 不生效？先确认作用域
很多开发者写完 resValue 发现 R.string.xxx 没变，根本原因是：它只对当前构建类型（buildType）生效，且必须放在对应 buildType 块内，而不是 defaultConfig 或 productFlavors 里。比如你写了 debug { resValue "string", "app_name", "MyApp-Debug" }，那只有 debug 变体能拿到这个值；release 还是用的 main/res/values/strings.xml 里的原始值。
常见错误现象：Build Variants 面板选的是 release，但你在 debug 块里改了 resValue，结果运行时看到的还是旧名字——不是没生效，是压根没走到那个分支。
-
resValue必须写在具体buildType块内（如debug、staging、release） - 同一资源名在不同
buildType中可以重复定义，不会冲突 - 如果某个
buildType没定义，就 fallback 到main目录下的资源
怎么让 debug 和 release 显示不同图标和包名
图标和包名不能靠 resValue 改——前者是文件资源，后者是 manifest 层级配置。得用更底层的机制：
- 图标：把不同 icon 放到
src/debug/res/mipmap-*/ic_launcher.png和src/release/res/mipmap-*/ic_launcher.png，Gradle 会自动合并 - 包名：用
applicationIdSuffix，比如debug { applicationIdSuffix ".debug" }，这样release是com.example.app，debug就是com.example.app.debug - manifest 元素：用
manifestPlaceholders注入动态值，比如debug { manifestPlaceholders = [appLabel: "MyApp Debug"] }，然后在AndroidManifest.xml里写android:label="${appLabel}"
注意：applicationIdSuffix 不影响 packageName（即源码里的 package 声明），只改最终安装 ID；而 manifestPlaceholders 只能替换 AndroidManifest.xml 里的占位符，不能改 Java/Kotlin 代码里的字符串。
resValue 类型写错导致编译失败
resValue 的第一个参数是资源类型，必须严格匹配 Android 资源系统支持的类型名，拼错或大小写不对都会报错，比如 "String"（首字母大写）或 "string-value" 都不行，只能是 "string"、"bool"、"integer"、"color" 等小写形式。
典型错误信息：Cannot resolve symbol 'resValue'（其实是 Groovy 解析失败）或 Could not get unknown property 'resValue' for BuildType——这往往是因为你把它写在了 android { } 外层，或者拼错了函数名（比如写成 resvalue）。
- 正确写法：
debug { resValue "string", "api_base_url", '"https://dev.api.example.com"' }（注意 URL 字符串要加双引号包裹） - 布尔值写法：
resValue "bool", "is_debug_build", "true"，Java 侧用getResources().getBoolean(R.bool.is_debug_build) - 整数写法：
resValue "integer", "max_retry_count", "3"，不用引号
多模块下 resValue 怎么跨模块生效
默认情况下，resValue 只对当前模块生效。如果你在 :app 模块的 build.gradle 里定义了 resValue，:core 模块是拿不到的——R 文件是按模块生成的，没有跨模块传递机制。
想让子模块也读到构建期配置，有两条路：
- 把配置下沉到子模块自己的
build.gradle里，各自定义对应的resValue（推荐，职责清晰） - 通过
buildConfigField+ 接口抽象，在子模块里读BuildConfig常量（适合纯逻辑开关，不适合 UI 资源） - 避免用
resValue做全局配置；改用gradle.properties+ 自定义 task 生成统一资源文件，再让所有模块依赖该文件（复杂，仅当强一致需求时考虑）
最容易被忽略的一点：资源合并优先级是 buildType > flavor > main，但这个顺序只在同一模块内有效；跨模块时，每个模块的资源树是独立的，不存在“覆盖”关系。
