升级Spring Boot 3.2与JDK17遇Mockito初始化异常求助

针对你遇到的MockitoException: Cannot instrument class because it or one of its supertypes could not be initialized错误，给你几个具体的排查和解决方向：

• 定位具体初始化失败的类
  开启Mockito的verbose日志，在测试类上添加@MockitoSettings(verboseLogging = true)，或者把测试日志级别调到DEBUG，这样能看到到底是哪个类（或其父类）初始化失败，进而找到触发问题的代码逻辑——大概率是静态代码块、静态成员初始化时出了问题，比如依赖了未加载的资源、触发了JDK17模块系统的访问限制。

• 对齐Spring Boot与Mockito的依赖版本
  Spring Boot 3.2默认绑定的是Mockito 5.x版本，别手动硬写Mockito的版本号，直接移除pom里自己指定的Mockito依赖，让Spring Boot的parent依赖管理来自动控制版本，避免版本不兼容的问题。

• 替换过时的Mockito API
  如果你还在使用MockitoAnnotations.initMocks()这种旧API，赶紧换成@ExtendWith(MockitoExtension.class)——JDK17对反射的限制更严格，旧API更容易触发类初始化时的权限问题。

• 调整JDK模块系统的访问权限

  • 如果是模块化项目（有module-info.java），给Mockito开放必要的模块访问权限，比如添加opens com.your.project.package to org.mockito;或者exports com.your.project.package to org.mockito;，让Mockito能正常反射操作你的类。
  • 非模块化项目的话，在测试的JVM参数里加--add-opens java.base/java.lang=ALL-UNNAMED这类参数，解决反射访问核心类的权限问题。

• 检查测试类的初始化逻辑
  看看测试类里是不是有@BeforeAll里的静态初始化逻辑触发了被测类的加载，或者用了静态Mock对象——换成@BeforeEach延迟初始化，或者避免静态Mock，减少类加载时的冲突。

• 排查第三方测试依赖冲突
  比如PowerMock这类旧测试库和Mockito 5.x不兼容，如果项目里用了PowerMock，要么换成MockK这类兼容JDK17的库，要么升级PowerMock到支持Mockito 5的版本。

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