如何优雅解决commons-io 2.19.0与2.4的重复类冲突问题？

嗨，这个重复类冲突的问题我在项目里碰过好多次了，咱们直接说最务实的解决方案，再分析其他选项的适用场景：

最优解：删除libs目录下的commons-io-2.4.jar，完全依赖Gradle管理的传递依赖 #

这绝对是长期维护最省心的方案，理由有三个：

• 依赖一致性有保障：Gradle的依赖管理系统就是为了统一版本、自动处理传递依赖而生的，手动放JAR本质上是绕开了这个机制，以后加新依赖很容易再出现版本冲突，维护成本会越来越高。
• 版本更安全可靠：2.19.0作为新版本，修复了2.4里可能存在的bug和安全漏洞，API上也完全向下兼容2.4的核心功能，升级不会有问题。
• 配置更干净：不需要写任何额外的exclude或者强制版本的配置，build.gradle代码更简洁，其他接手项目的开发者也不用花时间理解这些特殊规则。

其他方案的适用场景（非优先） #

如果你的项目有特殊限制，再考虑下面两种：

• 保留老JAR，排除传递依赖：只有当你的项目代码强依赖2.4版本的过时API，升级到2.19.0会直接编译报错或者运行异常时，才用这个方案。配置示例如下：

  // 排除某个依赖传递的commons-io
  implementation('引入2.19.0的那个依赖') {
      exclude group: 'commons-io', module: 'commons-io'
  }
  // 保留本地JAR的依赖
  implementation fileTree(dir: 'libs', include: ['*.jar'])
  

  但要注意，这种方式等于放弃了Gradle的依赖统一管理，后续每次加新依赖都要检查会不会又引入commons-io，非常麻烦。
• 用resolutionStrategy.force强制统一版本：这个方案比上面的稍好，但也不是最优。适合你既不想删除老JAR，又想统一用新版本的情况。配置示例：

  configurations.all {
      resolutionStrategy.force 'commons-io:commons-io:2.19.0'
  }
  

  不过这里有个小坑：如果你的老JAR里有新版本没有的类（这种情况极其罕见，因为commons-io的新版本只会加功能不会删核心类），强制版本可能会导致运行异常。而且手动JAR的存在还是会让依赖结构变复杂。

总结 #

除非项目有不可替代的历史代码依赖限制，否则优先删除手动放置的老JAR，完全依赖Gradle的传递依赖，这是最符合现代构建工具设计理念的做法，也是长期维护最省心的选择。

内容来源于stack exchange