Kotlin插件kotlin-android、kotlin.android、kotlin.jvm的区别与作用

你贴出的三个插件本质都是JetBrains提供的Kotlin编译支持插件，但命名规则、适用场景、版本控制逻辑有明确区别，逐个说明如下：

各插件的实际作用与差异 #

• kotlin-android
  这是早期Kotlin Android插件的短ID别名，属于Kotlin 1.4版本之前的旧写法，没有带官方组织命名空间。它的核心作用是给Android模块提供Kotlin代码编译能力，对接Android Gradle Plugin（AGP）的编译链路，把模块内的Kotlin代码编译为Android虚拟机可执行的字节码。目前这个ID仅做兼容保留，不会单独维护版本映射，很容易和项目内其他Kotlin组件出现版本错配，新版本Gradle会直接提示替换为全限定ID，新项目不建议使用。

• org.jetbrains.kotlin.android
  这是kotlin-android对应的官方正式全限定ID，从Kotlin 1.4开始成为Android场景下的标准Kotlin插件ID，核心功能和旧短ID完全一致，只是命名符合Gradle插件的规范要求，绑定了org.jetbrains.kotlin组织前缀。它在基础JVM编译能力之上，额外适配了Android的编译变体、源码集、View Binding/Data Binding、NDK互操作等专属特性，只能用在Android模块中，不能给纯JVM非Android项目使用。

• org.jetbrains.kotlin.jvm
  这是面向通用JVM平台的基础Kotlin编译插件，不绑定任何特定业务场景，不管是Spring后端、桌面JVM程序、纯Kotlin工具库还是Android项目，底层的Kotlin JVM编译能力都来自这个插件。它的核心特点是版本完全显式声明，不会被其他依赖隐式修改版本，会自动拉取对应版本的Kotlin编译器、标准库，完整支持协程、Kapt、反射等所有Kotlin JVM生态特性。
  你提到的协程场景优势确实存在：协程属于Kotlin标准生态组件，对Kotlin标准库版本一致性要求很高，如果用不锁版本的Android插件，很容易被其他传递依赖拉到低版本Kotlin标准库，导致协程API缺失、运行时崩溃，而显式声明这个插件的版本可以从根源上避免这类冲突。

选型指导 #

• 纯JVM非Android项目（后端、桌面程序、通用Kotlin工具库）：直接使用org.jetbrains.kotlin.jvm，显式指定固定的Kotlin版本即可，不要用另外两个Android专属插件。
• Android项目：
  1. 优先使用全限定ID的org.jetbrains.kotlin.android，不要用旧的短IDkotlin-android，避免不必要的兼容问题。
  2. 如果项目重度使用协程、或者需要严格统一全项目Kotlin版本，可以在项目根目录的Gradle配置中统一声明org.jetbrains.kotlin.jvm的版本，Android模块应用org.jetbrains.kotlin.android时会自动复用这个全局版本，不需要单独给Android插件指定版本，既保留Android专属适配能力，又能锁定版本避免协程相关的依赖冲突。
• 注意：不要在同一个模块中同时应用多个Kotlin编译插件，你贴出的配置里同时声明三个插件的写法是错误的，会触发重复编译、类冲突、版本不一致等编译异常。

纠正一个常见误区：org.jetbrains.kotlin.jvm并非所有场景的最优选择，它是基础通用插件，Android专属插件是在它的基础上做了大量平台适配，做Android开发不需要强行替换成jvm插件，只要做好全局版本锁定，协程的使用不会有任何问题。

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