资源重名会导致app:processDebugResources失败，需用--stacktrace或--info配合grep定位冲突项；resourcePrefix仅校验本模块新资源前缀，无法解决跨模块或aar内资源冲突；exclude不适用于res目录，唯一可靠解法是删除冗余定义或重命名并全局替换引用。
资源重名会直接导致 app:processDebugResources 失败，且错误提示模糊——它不告诉你哪两个模块撞了，只报“duplicate resource”或“AAPT2 error”。必须手动定位并干预，不能靠 Gradle 自动修复。
怎么快速定位冲突的资源名和来源模块
Gradle 不会在默认日志里展开具体冲突项，得用命令触发详细输出：
- 运行
./gradlew app:processDebugResources --stacktrace，错误末尾通常会列出第一个重复资源路径，如string/app_name - 更可靠的是启用 AAPT2 的详细模式：在
app/build.gradle的android块内加一行aaptOptions.cruncherEnabled = false（禁用图片压缩可减少干扰），再配合--info：./gradlew app:processDebugResources --info 2>&1 | grep -A5 -B5 "duplicate" - 如果仍不明确，直接检查
build/intermediates/packaged_res/debug/目录下是否已生成同名文件（如多个values/strings.xml都含app_name）
resourcePrefix 能防模块间资源重名吗
能，但只对 module 内新声明的资源生效，且有明显限制：
-
android { resourcePrefix "mylib_" }仅强制该 module 中所有新定义的资源 ID（@string/xxx、@layout/xxx等）必须以指定前缀开头，否则编译报错 - 它不重命名已有资源，也不影响其他 module 或 aar 里带进来的资源；所以无法解决“module A 和 module B 都定义了
@string/api_timeout”的问题 - 若多个 module 都设了相同 prefix（比如都设
"common_"），照样冲突——prefix 不是命名空间，只是校验规则 - 实际使用时建议每个业务 module 设唯一 prefix（如
"home_"、"profile_"），并配合 CI 检查，避免漏加
exclude 或 rename 资源文件本身可行吗
不可行。Gradle 的 packagingOptions.exclude 只作用于 META-INF、lib/** 等非资源目录，res/ 下的 XML、图片等资源文件无法被 exclude。
试图用 sourceSets 移除某个 res 目录会导致该 module 资源完全不可见；而用 AGP 的 variantFilter 或自定义 task 删除特定资源文件，极易破坏 R.java 生成逻辑，引发编译期或运行时 ResourceNotFoundException。
真正可用的路径只有两条：
-
删掉冗余定义：确认哪个 module 的资源是多余的（比如基础库已提供
@color/text_primary，业务 module 就不该再定义同名项） -
改名 + 全局搜索替换：对必须保留的资源，在定义处重命名（如
@string/home_api_timeout），并同步修改所有引用点——Android Studio 的Refactor → Rename能自动处理引用，但要注意跨 module 引用是否被识别（有时需手动改）
为什么 clean / rebuild / invalidate cache 都没用
因为资源重名是静态冲突，发生在 processDebugResources 阶段，属于构建逻辑校验，不是缓存污染问题。
执行 ./gradlew clean 或 Android Studio 的 Clean Project 只清空 build/ 目录，不影响源码中已存在的重复定义；Invalidate Caches and Restart 也只重置 IDE 索引，不会改变资源合并行为。
这类问题必须回到代码层解决：要么删一个，要么改一个名，没有绕过手段。最容易被忽略的是——第三方 aar 里也可能自带 res/，它和你本地资源一样参与合并，却常被当成“黑盒”忽略排查。
