本地构建正常，Docker环境Maven测试遇SurefireBooterForkException求助

问题原因 #

• 依赖版本冲突导致类缺失：BouncyCastle 1.58已移除org.bouncycastle.asn1.DEREncodable类（该类在1.50版本后被标记为过时，后续正式删除），而iTextPDF 5.5.13依赖BouncyCastle 1.49中的这个类。本地Windows环境下，要么是类加载顺序让旧版本类被优先加载，要么是测试代码未触发该类的调用路径，因此未暴露问题；但Linux Docker环境中Surefire的fork进程类加载机制更严格，直接触发了类找不到的错误。
• Surefire fork模式的跨平台类加载差异：Windows与Linux环境下，Surefire的fork进程构建classpath的逻辑存在差异。本地可能默认使用非fork模式，或fork模式下classpath自动包含了所有依赖；而Docker环境中fork进程的classpath未正确引入bcprov-jdk15on 1.58，或因依赖冲突导致有效classpath中无对应类。
• Docker镜像的依赖缓存/拉取异常：Docker镜像中的Maven可能缓存了错误版本的BouncyCastle包，或镜像源拉取的jar包不完整，导致classpath中缺少必要的类文件。

排查思路 #

• 确认依赖树并强制锁定版本
  • 在本地和Docker环境分别执行mvn dependency:tree，对比输出中BouncyCastle的版本和依赖传递路径，确认是否存在1.49与1.58的冲突。
  • 在项目pom.xml的<dependencyManagement>节点中显式声明bcprov-jdk15on 1.58版本，强制覆盖iTextPDF传递依赖的1.49版本，确保所有模块统一使用1.58。
• 调整Surefire配置验证fork模式影响
  • 查看项目中Surefire的配置，尝试添加<forkCount>0</forkCount>关闭fork模式，重新构建看是否能正常执行测试。若关闭后正常，说明问题出在fork进程的类加载逻辑。
  • 若fork模式必须启用，可配置additionalClasspathElements将bcprov-jdk15on 1.58的jar路径加入fork进程的classpath，或用classpathDependencyExcludes排除冲突的旧版本依赖。
• 验证iTextPDF与BouncyCastle的兼容性
  • 查阅iTextPDF 5.5.13官方文档，确认其兼容的BouncyCastle版本范围。若5.5.13不支持1.58，可选择降级BouncyCastle到1.49，或升级iTextPDF到支持1.58的版本（如5.5.14及以上）。
• 排查Docker镜像的Maven依赖有效性
  • 进入Docker镜像内部，执行mvn clean install -U强制更新依赖，避免缓存的旧依赖干扰。
  • 手动检查镜像中拉取的bcprov-jdk15on 1.58 jar包，确认是否包含DEREncodable类（若确实无此类，说明版本兼容性是核心问题）。
• 定位测试代码的触发路径
  • 本地执行mvn test -X开启调试日志，查看DEREncodable类的加载来源。若本地测试未触发该类加载，可编写针对性测试用例调用iTextPDF中依赖该类的API，验证本地是否真的不存在潜在问题。

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