此问题水于 2024 年 01 月，假如后面 gradle 出了什么好方法能解决这个问题，家祭无忘告乃翁，提前谢过看到这篇的各位大佬了。

结论

先说结论，Java 因为包名定义等原因，对同名包在编译时只能编译一个版本，具体版本通过 gradle 的版本决议或用户在 build.gradle 中的配置决定。

属于是学艺不精了，gradle dependencies 跑了快上百次才意识到整个包只能有一个版本的同名包。

踩坑实录

搞开发总是免不了用些大佬的轮子，然后搞 Java 开发就免不了用到 maven 和 gradle，然后总有那么一天，因为引的包有新有旧，突然就出现了依赖冲突。
就比如：别人新开发的包是基于 com.example:utils:3.5 做的，结果和以前引进来已经稳定使用的一个包的依赖冲突了，而这个旧包用的是 com.example:utils:1.0 的一个古早版本，旧包里用的方法新包早就删除了，新包里有的方法旧包那是必然没有，然后就得解决依赖冲突吧，exclude、resolutionStrategy、DependencyResolveDetails 什么方法都用了，可就是继续冲突。
然后一个一个版本去试，发现新引入的包需要的某个方法在 2.0 版本刚刚更新，而旧包的一个方法在 1.5 就已经删掉了，完全没有中间版本。

解决思路

基本没有思路，每个思路都相当痛苦。

1. 一来是升级旧包，但是这种牵一发而动整个屎山的事，建议找个阳光明媚的早晨，喝点咖啡开始肝。

2. 二来是把发生冲突的包（例如上面举例的 com.example:utils:3.5） 原仓库下下来，改个包名重新编译制品然后手动引入。但是如果你是间接依赖引发的依赖冲突，甚至是间接依赖的依赖，gradle dependencies 都扫描出 (*)了，这个想法就更不现实了。

3. 三来是去新包的原仓库提 Issue，求社区大神给你改编一版低版本依赖的包，或者自己成为社区大神，整一版低版本依赖的。

4. 直接开摆。

还有一点

最后分享一下查包的网站：

点击具体版本之后往下翻，可以看到 Compile Dependencies 一栏，现在引包都得先调查下，最好就是下图这种没有依赖的，只需要考虑 Java 版本匹配就行。