VSCode 运行 Scala 时的 Metals 语言服务器启动瓶颈分析

Metals 启动时卡在 Starting Metals… 或者长时间停在 Importing build…，这其实不是插件本身坏了，而是构建链条的某个环节断了。根据经验，90% 的问题根源在于 JDK/sbt 版本错配、网络源阻塞或者静态解析失败，跟 VSCode 本身的关系不大。

为什么 Metals 卡在 Starting Metals…？

这个状态意味着 Metals 还没能连上 sbt 启动的构建服务器（BSP）。根本原因通常出在 JVM 环境或者启动器下载环节：

• 你以为系统环境变量里配了 JDK 17 就万事大吉？实际上 VSCode 并不一定会用它，必须显式配置 metals.ja vaHome，指向 JDK 17 的绝对路径。
• JDK 21 或 JDK 8 被悄悄加载的情况很常见。目前（2026 年 6 月）Metals 的稳定支持范围仅限于 JDK 11–17，JDK 21 会导致 BSP 启动静默失败，连个错误提示都不给。
• 首次启动时 Metals 需要从 GitHub Releases 下载 metals-launcher.jar，国内用户经常卡在这一步——网络不给力就是不行。
• Windows 用户如果填了带尾部反斜杠的路径，比如 C:\Program Files\Ja va\jdk-17\，VSCode 解析时会直接跳过这个配置，等于白设。

Importing build… 卡住或超时的真正原因

这可不是单纯的“导入慢”，而是 Metals 尝试调用 sbt 启动 BSP 时被阻断了。常见情况包括：

• sbt 版本与项目不兼容。比如项目 project/build.properties 里锁定了 sbt.version=1.9.9，但你本地装的是 sbt 2.x——sbt 会静默拒绝连接，连个报错都没有。
• build.sbt 里如果包含运行时逻辑，比如 sys.env.get("CI") 或 scala.util.Properties.isWin，Metals 只做静态解析，遇到这类代码直接跳过整个段落，结果模块识别出来是空的。
• 国内源没配置的话，sbt 默认走 Ma ven Central 和 GitHub，依赖下载速度低于 10 KB/s 时，BSP 等待超时（默认 300 秒）后自动退出。
• 项目根目录下残留的 .metals/ 或 .bloop/ 文件夹，旧缓存里可能含有损坏的 BSP 描述符，导致新导入反复失败。

如何快速验证 Metals 是否真连上了？

别只看右下角的状态栏文字，那些容易骗人。用终端和日志交叉确认才是正解：

• 打开 VSCode 输出面板，切换到 Metals 日志页，直接搜索 BSP connection established。没找到这行字，就说明根本没连上。
• 在终端进入项目根目录，手动执行 sbt metalsEnable，观察输出。如果报 command not found 说明 sbt 没装，Unsupported Scala version 说明版本冲突。
• 右下角显示 Scala (Metals) 并不代表 Metals 在工作。必须打开一个 .scala 文件，看是否有类型提示，Ctrl+Click 跳转是否生效——实测出真知。
• 删掉 .metals/ 后重新导入，比重启 VSCode 有效得多。但注意别删 project/target/，那是 sbt 自己的缓存，删了反而更慢。

最后说一个容易被忽略的点：Metals 并不是一个“装完即用”的 IDE，它本质上是桥接器——一边靠 sbt 启动 BSP，一边靠 JDK 加载服务。只要任何一端的版本或路径有偏差，这座桥就会断在中间，而错误日志通常藏在输出面板第三页之后，需要耐心翻一翻。