1. 显式标记后仍出现初始化问题的原因 #

• 多模块配置传递遗漏：Gradle的Native Image参数若仅在根模块配置，部分子模块可能未继承该规则，导致标记的构建时初始化类在子模块构建中不生效。另外，Couchbase SDK等第三方依赖可能在内部触发SLF4J初始化，生成的SubstituteLoggerFactory实例被存入镜像堆，但触发初始化的依赖类未被标记为构建时初始化，引发冲突。
• 初始化规则被覆盖：Spring Boot Native插件或GraalVM内置元数据存在默认初始化规则，优先级高于手动添加的--initialize-at-build-time参数。比如Spring Boot会自动管理部分日志类的初始化时机，手动配置的参数可能被覆盖。
• SubstituteLoggerFactory的特殊逻辑：它是SLF4J的占位符实现，当实际日志框架（Logback）未完成加载时会被自动实例化。如果构建过程中某个组件提前触发了SLF4J的日志获取操作（比如Couchbase SDK的初始化逻辑），此时Logback还未就绪，就会生成该类的实例并进入镜像堆，但该类未被正确标记为构建时初始化，触发错误。

2. 依赖版本兼容性情况 #

• SLF4J 2.0.17 & Logback 1.5.18：官方宣称这两个版本原生支持GraalVM Native Image，但存在部分边缘场景的已知问题，比如Logback的LoggerContext在某些初始化顺序下会与SubstituteLoggerFactory产生冲突，或者SLF4J的占位符逻辑在Native Image构建时未被正确识别。
• Netty 4.1.119.Final：Netty对Native Image的支持较为成熟，该版本无重大兼容性问题，但需确保Netty相关类（如缓冲区、事件循环）被正确配置为运行时初始化，错误的初始化配置可能间接导致日志类的初始化异常。
• GraalVM 23.0.2：与Spring Boot 3.4.4的兼容性良好，但部分组合场景下，GraalVM的类初始化跟踪逻辑可能误判SLF4J相关类的初始化时机。

3. SLF4J及依赖适配GraalVM的最佳实践 #

• 优先使用Spring Boot原生配置：避免直接添加GraalVM参数，改用Spring Boot提供的spring.native.image.init-at-build-time属性（在application.properties或application.yml中配置），Spring会自动处理依赖传递的初始化规则，减少冲突。
• 统一多模块的Native配置：在Gradle根项目中通过subprojects块统一配置Native Image参数，确保所有子模块共享相同的初始化规则：

  subprojects {
      plugins.withId("org.graalvm.buildtools.native") {
          nativeImage {
              buildArgs.add("--initialize-at-build-time=org.slf4j.helpers.SubstituteLoggerFactory,ch.qos.logback.classic")
              buildArgs.add("--initialize-at-run-time=io.netty,java.net")
          }
      }
  }
  

• 生成并合并Native配置元数据：使用GraalVM的native-image-agent跟踪应用运行时的类初始化、反射等操作，生成完整的配置文件（reflect-config.json、init-config.json等），将这些文件放到各模块的src/main/resources/META-INF/native-image目录下，替代手动添加参数的方式。
• 排查冲突依赖：通过gradle dependencies命令检查是否存在其他日志框架依赖（如commons-logging、log4j），排除这些依赖避免与SLF4J产生冲突，防止SubstituteLoggerFactory被意外触发。
• 调试初始化触发源：添加GraalVM参数--trace-class-initialization=org.slf4j.helpers.SubstituteLoggerFactory，构建时查看哪个类触发了该类的初始化，针对性地将触发类标记为构建时初始化，从根源解决问题。

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