Gradle 插件版本相同仍报 unknown version：检查类路径供给

Gradle 提示插件 already on the classpath with an unknown version，但 buildSrc 依赖和根项目 plugins 块明明都写了 2.0.21。先区分“版本数字相同”与“插件版本跟踪器知道这个 ID 的来源”：前者不能替代后者。

例如 buildSrc 把 Kotlin Gradle plugin 当作普通实现依赖加入类路径，根项目又提出带版本的插件请求：

// buildSrc/build.gradle.kts 中的依赖片段
dependencies {
    implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:2.0.21")
}

// 根 build.gradle.kts 中的插件请求
plugins {
    id("org.jetbrains.kotlin.jvm") version "2.0.21" apply false
}

这两段不是完整构建文件，仓库与其他构建逻辑沿用项目既有配置。2.0.21 用来展示原配置冲突，实际插件版本仍须满足项目的 Gradle、JDK 兼容约束。这里真正冲突的是插件已经能从父类路径找到，但这条请求要求比较版本，而该 ID 没有可用的版本记录。

unknown 与 different version 对应两条分支

Gradle 9.8.2 的正式解析器先检查插件是否已经存在，再向插件版本跟踪器查询该 ID。记录缺失就报 unknown；有记录但与请求版本不同，才报 different version。因而把 2.0.21 重写一遍，或强行换成另一个数字，都不能补回来源信息。

还可能出现根项目请求 org.jetbrains.kotlin.jvm，子项目请求同一个 JAR 中的 org.jetbrains.kotlin.multiplatform。跟踪器按插件 ID 查版本，不能因为 JAR 相同，就保证两个 ID 都有相同记录。只观察依赖解析列表里有某个 Kotlin JAR，不足以证明带版本请求可通过。

让插件供给位置和应用位置一致

先查 buildSrc、约定插件、settings 与各项目中的 buildscript/plugins 声明。若 buildSrc 确实需要插件类，保留这份依赖，再让已经可以从该类路径获得插件的消费处不重复提出版本请求。例如在确认所需 ID 已可见的项目中：

plugins {
    id("org.jetbrains.kotlin.jvm")
}

这只适用于插件实现已经由审定的父类路径提供的情况。无版本请求不会替你下载任意版本，也不证明类路径上的插件就是预期版本；仍需核对 buildSrc 的依赖解析和实际应用行为。

若普通项目应该统一通过插件 DSL 管理版本，评估将不必要的插件实现依赖从 buildSrc 或 buildscript 供给路径移除，在统一的 plugins 声明中管理，再由子项目按既有约定应用。不能直接删除约定插件编译真正需要的实现依赖，否则错误会转移到 buildSrc 自身。

同 JAR 不同 ID 的工程，要逐项确认各 ID 的供给关系，不只修根项目的第一条请求。不要反射修改 Gradle 的版本缓存、手工替换插件 JAR，或在未知来源上直接认定版本兼容。

验收既要让原插件请求完成，也要检查原插件引入的任务和编译配置确实生效；多项目工程覆盖原来报错的子项目。确认没有因删除版本声明而换成另一份类路径实现。保存原声明位置及依赖锁定，必要时作为一组回退，避免剩下两套继续竞争的插件入口。