Gradle未使用声明的TestNG 6.14.3版本，改用7.0.0-beta4问题求助

看起来你遇到了Gradle依赖解析里的经典版本冲突——明明指定了TestNG 6.14.3，但Gradle却自动下载了7.0.0-beta4版本，这大概率是传递依赖在搞鬼。下面我一步步帮你分析原因并解决问题：

一、问题根源：传递依赖的版本冲突 #

Gradle默认的依赖解析规则是优先选择每个依赖的最高版本。你的某个直接依赖（比如reportng或其他库）可能在自身的依赖声明里要求了TestNG 7.0.0-beta4，Gradle在合并所有依赖需求时，就自动选用了更高的版本，覆盖了你显式指定的6.14.3。

二、定位冲突来源 #

先搞清楚到底是哪个依赖带进来了高版本的TestNG，执行下面的Gradle命令查看完整依赖树：

./gradlew dependencies --configuration testCompileClasspath

（Windows环境替换为gradlew.bat dependencies --configuration testCompileClasspath）

在输出结果里搜索testng，你会看到类似这样的结构：

testCompileClasspath - Compile classpath for source set 'test'.
+--- org.testng:testng:6.14.3
+--- org.uncommons:reportng:1.1.4
|    \--- org.testng:testng:7.0.0-beta4

这里就能明确看到是reportng引入了高版本TestNG，这就是冲突的源头。

三、强制使用指定版本的三种方法 #

方法1：直接强制TestNG版本 #

最快捷的方式是给你的TestNG依赖加上force: true，让Gradle忽略所有传递依赖的版本需求，强制使用你指定的版本：

testCompile group: 'org.testng', name: 'testng', version:'6.14.3', force: true

这种方法适合你明确确认6.14.3版本能兼容所有其他依赖的场景。

方法2：排除传递依赖中的高版本TestNG #

如果你不想全局强制，也可以针对引入高版本TestNG的依赖，排除它的TestNG传递依赖。比如针对上面找到的reportng，修改它的依赖声明：

compile group: 'org.uncommons', name: 'reportng', version:'1.1.4', exclude: [group: 'org.testng']

这样reportng就不会再引入它自带的TestNG版本，Gradle就会使用你显式指定的6.14.3。

方法3：启用依赖锁定（Dependency Locking） #

如果你的项目需要严格控制所有依赖版本，防止意外升级，可以启用Gradle的依赖锁定功能。执行命令生成锁定文件：

./gradlew dependencies --write-locks

这会在项目中生成gradle/dependency-locks目录，记录所有依赖的精确版本。之后Gradle会严格按照锁定文件中的版本下载依赖，不会再自动选择更高版本。

四、验证解决方案 #

修改配置后，执行./gradlew clean compileJava重新编译，或者再次执行依赖树命令，确认TestNG的版本已经是6.14.3即可。如果还有问题，再检查是否有其他依赖也引入了高版本TestNG。

内容的提问来源于stack exchange，提问作者steve