VS Code配置Gradle需安装Extension Pack for Java、启用Language Support for Java™、确保build.gradle在根目录且语法合法；国内用户须在build.gradle中优先配置阿里云Maven镜像，避免依赖解析卡顿。
VS Code 默认不带 Gradle 支持，必须装对扩展、配好 JDK、确保 gradlew 可执行，三者缺一不可；否则任务不显示、依赖不解析、类名报红都是表象，根子在项目没被 Java Language Server 加载进来。
Gradle for Java 扩展要不要单独装？
不用。截至 2026 年，Extension Pack for Java 已内置 Gradle 支持能力，单独再装 Gradle for Java（VMware 版）反而可能引发冲突或任务重复注册。
只需确认以下两点：
- 已安装并重启了
Extension Pack for Java（作者 Microsoft） -
Language Support for Java™ by Red Hat处于启用状态（它是底层语言服务，Gradle 依赖它解析源码）
如果侧边栏没有出现 Gradle 图标，不是插件没装全，而是项目根本没被识别——先检查 build.gradle 是否在根目录、语法是否合法（比如 plugins { id 'java' } 缺失会导致整个构建脚本被跳过）。
立即学习“Java免费学习笔记（深入）”；
为什么 build.gradle 存在，但 Gradle 任务列表为空？
常见原因不是插件问题，而是 VS Code 没触发 Gradle 同步。它不会自动运行 ./gradlew --dry-run 来探测可用任务。
手动触发方式有三种：
- 右键点击
build.gradle文件 → 选择Link Gradle Project - 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Java: Import Projects并执行 - 打开命令面板，输入
Gradle: Refresh Projects（需确保 Gradle 功能已激活）
若仍无反应，终端里跑一遍 ./gradlew tasks 看是否报错。常见失败点：gradle/wrapper/gradle-wrapper.properties 中的 distributionUrl 被墙、JDK 版本低于 gradle-8.x 要求的 JDK 17+、或 settings.gradle 里漏写了 include 'submodule-name'（多模块场景）。
国内用户必做的仓库镜像配置
Gradle 默认走 https://repo.maven.apache.org/maven2，国内直连极大概率超时或卡在 Resolving dependencies 阶段，且这个卡顿不会报错，只表现为“任务一直加载中”或“References 下看不到依赖”。
最直接有效的改法是在项目级 build.gradle 里显式声明阿里云镜像：
repositories {
maven { url 'https://maven.aliyun.com/repository/public' }
mavenCentral()
}
别去动全局 ~/.gradle/init.gradle——它对 wrapper 项目无效，而且容易和 CI 环境行为不一致。
注意顺序：把阿里云 URL 放 mavenCentral() 前面，否则 fallback 到中央仓库还是会卡。
gradle run 在终端能跑，VS Code 里报 Could not find or load main class
这是 VS Code Gradle 插件的固有限制：它执行 run 任务时，不读取 gradle.properties，也不自动应用 application 插件里的 mainClass 配置。
解决办法只有两个：
- 在
build.gradle中显式配置run任务：tasks.named('run', JavaExec) { mainClass = 'com.example.Main' } - 放弃插件的
run任务，改用 VS Code 的调试功能：在launch.json里写死"mainClass"，靠 JVM 启动器执行，更稳定也更可控
本质上，VS Code 的 Gradle 集成偏重构建生命周期（build、test），而不是运行时控制；把运行逻辑交给 launch.json 或终端，反而是更少坑的做法。
