真正有效的解法是控制依赖图的“来源”和“版本归属”，而非粗暴删除：先用./gradlew :app:dependencies --configuration releaseRuntimeClasspath定位冲突路径，再通过exclude精准切断传递链或resolutionStrategy.force统一强制版本，并排查libs/下本地jar/aar引发的隐性冲突。
直接删掉重复的包不能解决问题，反而可能引发 NoClassDefFoundError 或运行时崩溃。真正有效的解法是控制依赖图的“来源”和“版本归属”，而不是粗暴删除。
用 ./gradlew :app:dependencies 定位具体冲突路径
这是所有操作的前提——不看树，就排除，纯靠猜。执行命令后注意三点：
- 输出默认包含几十个 configuration，太冗长，加
--configuration releaseRuntimeClasspath（或debugCompileClasspath）聚焦编译期实际参与的依赖 - 搜索关键词如
okhttp、gson、androidx.core，观察同一 group 下是否出现多个 version（例如com.squareup.okhttp3:okhttp:3.12.12和com.squareup.okhttp3:okhttp:4.12.0并存） - 留意缩进层级：缩进越深，说明该依赖是被某个第三方库“传递引入”的，而非你主动声明的
在 implementation 中用 exclude 剔除传递依赖
不是所有冲突都适合全局干掉，多数情况只需切断某条传递链。语法必须严格：
implementation('com.tencent.mm.opensdk:wechat-sdk-android-without-mta:6.8.0') {
exclude group: 'com.android.support', module: 'support-v4'
exclude group: 'com.google.code.gson', module: 'gson'
}
-
group和module必须与dependencies输出中显示的完全一致（大小写、连字符都不能错） - 不要写
exclude 'gson'这类模糊写法，Gradle 不识别 - 如果一个库同时带入了
okhttp和okio，且你已统一管理前者，通常也要一并排除后者，否则可能因版本不匹配触发IncompatibleClassChangeError
用 resolutionStrategy.force 统一强制版本
当多个路径引入同一 group+module、但版本杂乱（比如 5 个不同 androidx.lifecycle:lifecycle-viewmodel 版本），手动 exclude 会漏且难维护，此时该上策略：
configurations.all {
resolutionStrategy {
force 'androidx.lifecycle:lifecycle-viewmodel:2.7.0'
force 'androidx.lifecycle:lifecycle-livedata:2.7.0'
force 'com.squareup.okhttp3:okhttp:4.12.0'
}
}
- 放在项目级
build.gradle的subprojects或模块级android块外（即与dependencies同级） -
force优先级高于依赖声明顺序和路径长度，能覆盖 Maven 默认仲裁逻辑 - 慎用
useLatestVersion()—— 它不保证 ABI 兼容，尤其对androidx.*和com.google.guava这类敏感库
警惕 libs/ 目录下的本地 jar/aar 与远程依赖打架
这是最容易被忽略的隐性冲突源。现象是：明明 dependencies 树里没看到重复，但编译仍报 Program type already present。
- 用 Android Studio 的
Project视图切到Project Files模式，展开app/libs/，检查是否有gson-2.8.9.jar这类文件，同时又在build.gradle里写了implementation 'com.google.code.gson:gson:2.10.1' - 解决方法只有两个：要么删掉
libs/下的 jar，全部走 Gradle 管理；要么把 Gradle 依赖改为compileOnly（仅编译期可见，不打包进 APK），确保运行时只用本地 jar - 如果是 aar 文件，还要注意它内部是否已 embed 了某些依赖（可用
unzip -l xxx.aar | grep classes.jar查看），这种嵌套更难排查
最麻烦的情况不是版本不一致，而是两个 aar 里各有一个同名类（比如 com.example.util.Logger），且路径、签名完全一样——这时 Gradle 无法自动仲裁，必须人工确认哪个实现是可信的，再通过 exclude 或重构依赖结构来隔离。这类问题不会在编译时报错，而是在特定机型或 Android 版本上静默失效。
