Atom 不适合做 Scala 主力编辑器，因其插件停更、无法对接 Metals/Bloop，类型推导失败、跳转失效、不支持 Scala 3；仅可作轻量查看或编辑，编译调试必须依赖终端或 Jupyter+Almond。
为什么 atom-scala 和 ide-scala 插件现在完全不可靠
这两个插件依赖旧版语言服务器协议（LSP v1），而 Metals 使用的是 LSP v3+；它们也无法连接 Bloop 或 sbt 的构建状态。常见现象包括：
-
Cannot resolve symbol错误满屏，但实际代码完全合法 - Ctrl+Click 跳转到空文件或错误位置
- 修改
build.sbt后，Atom 完全无响应，也不提示重载 - 输入
given或using（Scala 3 关键字）时，语法高亮直接失效
根本原因：插件作者早在 2021 年就停止维护，且未适配 sbt 1.8+ 的 BSP 协议变更。强行启用只会干扰终端手动编译流程。
仅保留 language-scala 提供基础语法高亮
这是唯一还能正常工作的插件，只负责着色和括号匹配，不介入构建或类型检查。启用前必须：
- 卸载所有其他 Scala 相关插件（尤其是
ide-scala、atom-scala、scala-tools） - 确认系统 PATH 中已存在
sbt和scalac：sbt --version和scalac -version都应返回有效输出 - 不要在 Atom 设置里开启 “Auto compile on save” 类选项——它没有后端支撑，只会报错
该插件不会识别 .sc（Scala CLI 脚本）文件，如需支持，需手动在 Atom 设置中将 .sc 关联到 source.scala 语法。
手动编译调试必须依赖终端，Atom 不参与构建流程
Atom 在此场景下纯属文本查看器。真实开发流只能是：
- 在 Atom 中写完
.scala文件后，切换到项目根目录终端 - 运行
sbt compile查语法/类型错误；sbt test运行测试；sbt run启动主程序 - 错误定位靠终端输出的行号，而非 Atom 内联提示（它根本没有）
- 若用
scala-cli，则改用scala-cli compile .，同样与 Atom 无关
注意：sbt 第一次运行会下载大量依赖，耗时可能超过 2 分钟，这不是 Atom 卡顿，是构建工具本身行为。
如果非要交互式执行，走 Jupyter + Almond，绕过 Atom
Atom 的 Hydrogen 插件曾支持 Scala Kernel，但自 2022 年起不再兼容 Almond 0.12+，且 Hydrogen 本身也已归档。可行路径只剩：
- 安装 Almond（推荐用
coursier install --force almond，避免手动 bootstrap） - 执行
almond --install注册内核 - 用
jupyter notebook或nteract打开.ipynb，选 Scala 内核 - Atom 仅用于编辑
.scala源码，再复制粘贴到 Notebook 中执行
这个组合里，Atom 仍是哑终端——所有类型检查、依赖解析、REPL 状态都由 Jupyter 和 Almond 承担。
真正需要写、测、调 Scala 代码时，语言服务器的稳定性比编辑器颜值重要得多；Metals 启动慢几秒，换来的是整套类型系统支撑 —— 这个权衡点，很多人一开始没意识到。
