VS Code无法解析build.gradle.kts声明的Gradle依赖如何解决

结合现有现象可直接锁定核心问题：Java语言服务器未成功关联Gradle项目生成的依赖路径列表。
对应佐证点：

• JDK内置类可正常解析，说明Java语言服务器本身可正常识别项目的JDK编译配置
• 命令行执行Gradle构建可成功完成，说明项目本身的Gradle配置、依赖拉取流程无问题
• Java Projects面板下Referenced Libraries为空，说明语言服务器从未获取到外部依赖的Jar包路径
• 相同项目在IntelliJ IDEA中可正常运行，排除项目文件本身损坏的可能

• 校验版本兼容性：当前使用的VS Code 1.52.1发行时间较早，搭配的redhat.java扩展对Gradle Kotlin DSL（build.gradle.kts）的解析能力有限，无法自动识别脚本中声明的依赖配置。可先执行code --list-extensions --show-versions命令核对redhat.java的版本，匹配VS Code版本安装兼容范围内的最高版本Java扩展。
• 强制触发依赖同步：在已安装Gradle适配扩展的前提下，打开VS Code命令面板，执行Gradle: Sync Java Project命令，强制拉取Gradle生成的classpath清单到Java语言服务器，跳过自动解析脚本失败的兜底流程。
• 排查扩展冲突：当前扩展列表中存在多份冗余扩展：
  • 重复的Kotlin语法解析扩展（fwcd.kotlin、mathiasfrohlich.Kotlin）
  • 非项目类型匹配的Maven管理扩展（vscjava.vscode-maven）
    这类扩展会抢占Gradle脚本的解析优先级，临时禁用上述非核心扩展后，重新执行Java: Clean the Java language server workspace命令完成工作区重建，再重新导入项目。
• 校验远程开发路径匹配：当前安装了WSL远程扩展，如果项目存储在Windows本地路径而非WSL内部路径，会导致Gradle生成的依赖缓存路径、Jar包存储路径和Java语言服务器的读取路径不匹配，此时即使命令行Gradle构建成功，语言服务器也无法定位到对应依赖Jar包，无法填充Referenced Libraries列表。

注意：完成所有调整后，需要完全关闭VS Code再重新打开项目，避免旧的缓存进程残留影响识别结果。

内容的提问来源于stack exchange，提问作者Peter V. Mørch