仅Linux环境下SpringBoot+Cucumber测试出现@TestConfiguration的proxyBeanMethods属性别名错误求助

看起来你遇到的这个问题真的挺诡异的——Windows上一切正常，到Linux就炸，而且JDK、Maven、依赖版本都核对过，m2也清过了，这种环境一致但结果不同的问题，十有八九是类路径依赖冲突或者加载顺序差异导致的，毕竟Linux和Windows的文件系统对文件名的排序/处理逻辑不一样，很可能在Linux下旧版本的Spring类被先加载了。

先抓核心：为什么会出现这个错误？ #

你看到的proxyBeanMethods属性不存在的错误，本质是你的测试代码在Linux下加载了Spring 5.x版本的@Configuration注解——因为proxyBeanMethods是Spring 6.x才新增的属性，Spring 5.x的@Configuration根本没有这个方法。而Windows下类加载顺序刚好加载了正确的Spring 6.1.4版本的注解，所以没报错。

具体排查&解决步骤： #

1. 先确认Linux下的依赖树有没有旧Spring版本

先在Linux上跑这个命令，把所有依赖树导出来，重点搜spring-context的版本：

mvn dependency:tree > dependency-tree.txt
grep "org.springframework.context" dependency-tree.txt

看看输出里有没有除了6.1.4之外的版本（比如5.x的任何版本）。如果有，那就是某个依赖偷偷引入了旧版本的Spring Context，这时候需要在pom.xml的<dependencyManagement>里强制锁定版本：

<dependencyManagement>
    <dependencies>
        <!-- 强制所有依赖使用Spring 6.1.4的context包 -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>6.1.4</version>
        </dependency>
    </dependencies>
</dependencyManagement>

2. 检查你的Cucumber Spring依赖是否正确

确保你用的是Cucumber官方的Spring整合依赖，版本和SpringBoot匹配：

<dependency>
    <groupId>io.cucumber</groupId>
    <artifactId>cucumber-spring</artifactId>
    <version>7.23.0</version>
    <scope>test</scope>
</dependency>

不要混用旧的cucumber-spring-boot或者其他第三方的Spring整合依赖，否则容易引入冲突。

3. 别在TestRunner上乱加@Configuration/@TestConfiguration

你的TestRunner只需要负责Cucumber的测试引导，不需要加配置类注解！之前你加@Configuration(proxyBeanMethods = false)完全是画蛇添足，反而会触发类加载问题。正确的TestRunner应该是这样的：

import org.junit.platform.suite.api.ConfigurationParameter;
import org.junit.platform.suite.api.IncludeEngines;
import org.junit.platform.suite.api.SelectPackages;
import org.junit.platform.suite.api.Suite;
import static io.cucumber.junit.platform.engine.Constants.PLUGIN_PROPERTY_NAME;

@Suite
@IncludeEngines("cucumber")
@SelectPackages("your.test.package.path") // 替换成你的测试包路径
@ConfigurationParameter(key = PLUGIN_PROPERTY_NAME, value = "pretty")
// 这里啥配置类注解都不要加！
public class TestRunner {
}

如果需要自定义测试Bean，单独写一个配置类：

import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;

// Spring 6+的@TestConfiguration原生支持proxyBeanMethods，放心用
@TestConfiguration(proxyBeanMethods = false)
public class TestAppConfig {
    // 你的测试Bean定义
}

4. 检查Linux上的Maven全局配置

看看Linux用户目录下的~/.m2/settings.xml，有没有配置镜像或者Profile强制引入了旧版本的Spring依赖？比如有些公司的内部镜像会把某些依赖指向旧版本，或者Profile里硬编码了Spring 5的版本。

5. 终极排查：打印类加载日志

如果上面的方法都没用，就加JVM参数打印类加载路径，看看@Configuration是从哪个JAR里加载的：
在pom.xml的maven-failsafe-plugin里加这个配置：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>3.11.0</version>
    <configuration>
        <argLine>-verbose:class</argLine>
    </configuration>
</plugin>

然后跑mvn verify，在输出里搜org.springframework.context.annotation.Configuration，会看到类似这样的行：

[Loaded org.springframework.context.annotation.Configuration from file:/home/xxx/.m2/repository/org/springframework/context/spring-context-6.1.4.jar]

如果显示的是5.x的JAR，那就是问题根源，找到引入这个JAR的依赖，排除掉或者强制升级。

最后补充 #

这种跨环境的类加载问题真的很坑，我之前也遇到过——Windows下因为文件名大小写不敏感，新版本的JAR被先加载，Linux下大小写敏感，旧版本的JAR排在前面，就出问题了。重点就是揪出旧版本的Spring依赖，强制锁定版本应该就能解决！

内容来源于stack exchange