迁移至oshai kotlin-logging后，如何获取KLogger底层SLF4J Logger？

一、从KLogger获取底层SLF4J Logger #

oshai kotlin-logging 5.x+不再默认继承SLF4J Logger，但提供了适配方案来获取底层SLF4J实例：

1. 引入SLF4J适配依赖
   先确保项目已引入SLF4J API（1.x或2.x），再添加对应版本的kotlin-logging SLF4J适配模块：

   • 适配SLF4J 1.x的Gradle示例：

     implementation("io.github.oshai:kotlin-logging-slf4j1:5.x.x")
     

   • 适配SLF4J 2.x的Gradle示例：

     implementation("io.github.oshai:kotlin-logging-slf4j2:5.x.x")
     

2. 通过扩展函数转换为SLF4J Logger
   引入适配模块后，可使用asSLF4JLogger()扩展函数将KLogger实例转换为SLF4J Logger，传入遗留类：

   import io.github.oshai.kotlinlogging.KotlinLogging
   import io.github.oshai.kotlinlogging.slf4j.asSLF4JLogger
   
   class MyClass : MyLegacyClass(log.asSLF4JLogger()) {
       companion object {
           private val log = KotlinLogging.logger {}
       }
   }
   

   若扩展函数不可用，也可直接通过SLF4J原生API创建Logger传入：

   import org.slf4j.LoggerFactory
   
   class MyClass : MyLegacyClass(LoggerFactory.getLogger(MyClass::class.java)) {
       // 同时保留kotlin-logging的KLogger供自身业务日志使用
       companion object {
           private val log = KotlinLogging.logger {}
       }
   }
   

二、在Kotlin类中仅使用SLF4J的可行性及影响 #

可行性：完全可行 #

SLF4J是通用日志门面，Kotlin作为JVM语言完全兼容其API，直接使用org.slf4j.Logger和LoggerFactory无技术障碍。

核心影响： #

• 丢失kotlin-logging的Kotlin专属特性：
  无法使用KLogger的DSL风格日志（如log.info { "用户$userId已登录" }），只能用SLF4J的占位符语法（log.info("用户{}已登录", userId)），失去了懒加载日志消息、避免不必要字符串拼接的优势。
• 缺少Kotlin适配功能：
  比如简化的日志上下文处理、针对Kotlin类型的日志适配、更简洁的伴生对象日志声明等特性都无法使用。
• 代码风格不一致：
  若项目其他模块使用kotlin-logging，仅部分类用SLF4J会导致代码风格割裂，增加维护成本。
• 性能差异可忽略：
  两者最终都会绑定到具体日志实现（如Logback、Log4j2），性能上几乎无差异，核心区别在开发体验和代码简洁度。

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