VS Code 通过 Metals 插件可高效支持 Scala 开发：需安装官方 Metals 插件、用 sbt new 创建标准项目结构、遇“No build target”时删 .bsp 和 target 目录重试、调试时设 fork := false。
VS Code 本身不原生支持 Scala，但通过正确组合插件与构建工具，完全可以胜任日常开发——关键在于选对插件、配好构建器、绕开常见陷阱。
安装 Metals 插件并确保使用官方推荐的启动方式
Scala 在 VS Code 中的核心支持来自 Metals（由 Scala Center 维护），不是其他名字相似的旧插件。必须从 VS Code 扩展市场安装 “Metals” by Scalameta，而非 “Scala (sbt)” 或 “Scala Syntax” 等辅助插件。
安装后不要手动启动服务器；Metals 会自动检测项目根目录下的 build.sbt 或 project/build.properties，并根据其中指定的 Scala 版本下载对应语言服务器。若未触发，检查：
-
build.sbt文件是否在工作区根目录（不是子文件夹） - 文件中是否包含有效
scalaVersion := "3.3.3"或scalaVersion := "2.13.14"声明 - 是否已安装
sbt（v1.9+ 推荐）且能从终端运行sbt --version
用 sbt 创建标准 Scala 项目结构，避免手工建目录
Metals 依赖 sbt 的约定优于配置（convention over configuration），手工创建 src/main/scala 目录但缺少 build.sbt，会导致无法识别源码、无代码补全、类型跳转失效。
推荐用 sbt 命令初始化：
sbt new scala/hello-world.g8
该命令会生成符合 Metals 识别规范的完整结构，包括：
-
build.sbt（含明确scalaVersion） -
project/build.properties（指定 sbt 版本） -
src/main/scala/Hello.scala（可立即被 Metals 加载）
若已有非标准结构，不要强行修改；用 sbt new 新建一个标准项目，再把源码复制进去。
遇到 “No build target found” 错误时优先检查 .bsp 目录和构建缓存
这是 Metals 最常见的报错，表面是找不到构建目标，根源通常是构建过程卡在某处或元数据损坏。
先尝试以下步骤（按顺序）：
- 关闭 VS Code，删除项目根目录下的
.bsp和target目录 - 重新打开文件夹，等待 Metals 底部状态栏显示 “Importing build…” 而非 “Importing build (failed)”
- 若卡住超过 2 分钟，打开 VS Code 内置终端，手动运行
sbt clean compile，观察是否有编译错误或网络问题（如 Ivy 仓库超时） - 确认
~/.sbt/1.0/plugins/plugins.sbt中没有引入冲突的 sbt 插件（例如旧版sbt-assembly可能干扰 Metals）
调试 Scala 代码需额外启用 sbt-dynver 或禁用 fork
VS Code 默认调试器（通过 launch.json 配置）无法直接 attach 到 sbt 启动的 JVM 进程，因为 sbt 默认启用 fork := true，导致实际运行的是子进程。
两种可行方案：
- 在
build.sbt中临时添加：Compile / run / fork := false，然后用 Metals 的 “Run” 按钮（绿色三角）直接执行主类 - 更稳妥的方式：安装
sbt-dynver插件并配置javaagent，但仅建议进阶用户尝试；日常开发优先用第一种
注意：修改 fork 后，sbt run 和 Metals Run 行为一致，但 sbt test 仍可能独立 fork，调试测试需另配。
真正卡住的地方往往不是插件装没装，而是 build.sbt 里一行隐式版本声明没写对，或者 .bsp 目录残留了上一次失败的中间状态——删干净再试，比查文档更快。
