Kotlin插件默认依赖kotlin-stdlib及JVM编译配置相关问题

1. kotlin-stdlib是否可以避免手动添加？手动添加有什么弊端？ #

从Kotlin 1.4版本开始，官方kotlin、kotlin-android Gradle插件已经默认会自动为所有Kotlin源集添加对应版本的kotlin-stdlib依赖，正常情况下完全可以删除手动声明的org.jetbrains.kotlin:kotlin-stdlib:${versions.kotlin}配置。仅当你使用的Kotlin版本低于1.4时，才需要手动引入该依赖。

手动添加kotlin-stdlib的弊端如下：

• 容易引发版本冲突：如果手动声明的stdlib版本和项目引入的Kotlin插件版本不一致，会触发依赖冲突，轻则出现编译警告，重则导致运行时类找不到、方法签名不匹配等崩溃问题
• 增加维护成本：冗余的声明会提高版本升级的工作量，升级Kotlin版本时需要同步修改插件和stdlib的版本号，漏改就会触发上述版本冲突问题
• 多平台项目易出现变体错误：如果是KMP项目，手动引入JVM版本的stdlib可能会被错误引入到JS、Native等其他平台模块，导致编译失败

2. 纯Kotlin开发的Android应用能否移除compileOptions配置块？ #

你提到的配置块如下：

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
  kotlinOptions {
    jvmTarget = "1.8"
  }
}

如果你的项目100%使用Kotlin开发，没有任何Java源码，也没有引入使用Java 8+特性的三方依赖，理论上可以仅移除compileOptions块，该配置仅作用于Java源码的编译规则，对Kotlin代码编译无影响。但有两点需要注意：

• kotlinOptions.jvmTarget配置不能删除，该配置控制Kotlin编译器生成的字节码的JVM版本，和Java编译规则无关
• 保留compileOptions属于低成本的防御性配置，如果后续有新增Java代码、或者引入的三方依赖用到Java 8+特性，没有该配置可能会触发编译错误

3. kotlinOptions.jvmTarget设置为"11"有什么负面影响？ #

字节码生成层面的变化 #

将jvmTarget设置为11后，Kotlin编译器会生成符合JDK 11规范的字节码，可支持JDK 11引入的字节码优化特性（如部分invokedynamic优化、字符串处理优化等），运行效率相比JVM 8字节码有小幅提升，同时可直接调用JDK 11新增的系统API。

兼容性负面影响 #

• Android端运行限制：只有Android 13（API 33）及以上系统内置了JDK 11字节码的完整支持，如果你的App最低兼容版本低于API 33，必须开启AGP的核心库desugaring才能兼容低版本设备，否则低版本设备运行时会出现类找不到、方法不存在的崩溃
• 三方依赖兼容性问题：部分老旧的三方库是针对JDK 8编译的，在JVM Target 11的编译环境下可能出现反射调用失败、字节码增强失败等兼容性问题
• 跨JVM环境运行限制：如果编译产物需要在桌面JVM环境运行，只有JRE 11及以上版本才能加载JVM Target 11生成的字节码，低于11版本的JRE会直接抛出类加载错误

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