“Windows 上装 Scala”这件事网上搜一下能出来几十篇教程但真正照着抄的人十个里有四五个会卡在环境变量上两三个会卡在版本不匹配上。原因很简单——Scala 不是装完就能跑的独立软件它跑在 JVM 上安装顺序、JDK 版本、Scala 版本之间的关系任何一个环节选错都会让你绕一大圈。这篇文章就把 Windows 上安装 Scala 的完整流程写清楚先装什么、后装什么、每个选项怎么选、装完怎么验证以及我实际踩过的报错和排查思路。不管你是为了跟着 Spark 教程做实验还是想入门 Scala 这门语言读这一篇基本够了。1. 安装前必须理清的两个选型问题1.1 为什么必须先装 JDK再谈 Scala 安装很多人第一次安装 Scala 时习惯性地把它当成 Python 或者 Node.js 那种“下一个安装包直接能用”的运行时。实际上完全不是一回事。Scala 的编译器 scalac 是用 Java 写的它做的事是把 .scala 源文件编译成 .class 字节码然后交给 JVM 来执行。换句话说Scala 本身没有运行时JVM 就是它的运行时。所以安装顺序非常明确先装 JDK再装 Scala。JDK 全称 Java Development Kit里面除了包含运行 Java 程序需要的 JREJava Runtime Environment之外还带了一整套编译和开发工具。Scala 编译器和构建工具 sbt 在运行时会检查 JAVA_HOME 环境变量如果它指向了 JRE 而不是完整 JDK或者干脆没设置scalac 就会直接报错退出。有些教程会推荐你先只装 JRE 试试这是典型的坑。JRE 只能让已经编译好的 class 文件跑起来但 scalac 编译源码时需要的 javac 等相关工具并不在 JRE 里。哪怕你只是想在 REPL 里写两行表达式Scala 也更喜欢完整的 JDK 环境否则后续跑 sbt 时几乎必出问题。1.2 Scala 3 还是 Scala 2.13版本选择直接影响后续工具链安装之前还有一件事需要确定装 Scala 2 还是 Scala 3。这不是“哪个新就选哪个”这么简单而是要看你的下游工具链。先看 Scala 2 阵营。目前最常用的是 2.13.x 系列比如 2.13.16。这个版本最大的优势是生态兼容性好大量老牌开源项目都建立在它的基础上。尤其是大数据领域Apache Spark 在 3.x 系列里主要就是基于 Scala 2.12 和 2.13 构建的。如果你装 Scala 是为了学 Spark 或者跑一些老的 Flink 项目那么老老实实选 Scala 2.13.x 就行。再看 Scala 3。它是这门语言新的主版本语法更现代、编译器也更先进比如引入了枚举、上下文抽象等新特性。Scala 3 编译器能够“读懂”用 Scala 2.13 编译出来的库所以理论上你能在 Scala 3 里使用大部分老库。但反过来Spark 官方并没有基于 Scala 3 的版本这点很现实。我的建议是如果你明确知道自己学 Scala 是为了下一步学 Spark或者公司老项目用 Scala 2那就选 Scala 2.13.x如果你只是纯粹想学这门语言对大数据生态没有刚需选 Scala 3 完全没问题而且我推荐你直接从 Scala 3 开始因为它就是未来。1.3 JDK 版本怎么选不是越新越好JDK 版本的选择同样会影响 Scala 能否正常工作。Scala 编译器虽然在持续适配新 JDK但每个版本对 JDK 的支持范围是有限的。JDK 版本适合场景与 Scala 的兼容性JDK 8老项目、老版本 Spark/HadoopScala 2.12/2.13 兼容性最好JDK 11很多公司生产环境的保守选择兼容 Scala 2.13 和 Scala 3JDK 17当前新项目的稳妥选择长期支持兼容 Scala 2.13.4 和 Scala 3JDK 21最新 LTS适合纯新项目需要 Scala 2.13.12 或 Scala 3.3如果你打算跑 Spark我建议使用 JDK 8 或 JDK 11配合 Scala 2.13.x这是大数据领域最常见的组合。如果你只是学 Scala直接用 JDK 17配合最新的 Scala 3.3 LTS 或 Scala 2.13.16 都没有问题。JDK 的发行版我推荐用 Eclipse Temurin社区里常用的 OpenJDK 发行版或者微软 OpenJDK 17主要是免费、没有额外授权问题安装包也好找。安装时记住安装路径配置环境变量的时候要用。2. Windows 上安装 Scala 的三种方式与对比2.1 官方 MSI 安装包适合新手的“一路下一步”模式Scala 官方在 scala-lang.org 的下载页面提供了 Windows 平台的 .msi 安装包这个方式最直观适合刚接触开发环境的新手。下载完 msi 之后双击运行安装向导会让你选择安装目录默认是 C:\Program Files\Scala\scala-x.xx.x。这一步有一点值得注意安装路径里带有空格大部分情况下没问题因为编译器内部会正确处理带引号的路径但少数命令行工具和脚本在解析带空格的路径时会出怪毛病。如果你之后要配合一些底层工具链使用我建议在向导里手动把安装目录改成一个无空格路径比如 C:\scala\scala-2.13.16。MSI 安装程序的本质其实就是解压 Scala 文件到指定目录并往系统 PATH 环境变量里加入对应的 bin 目录。整个过程不需要额外处理什么依赖因为它假定你已经装好 JDK 了。所以顺序很重要一定要先完成 JDK 安装和环境变量配置再安装 Scala。安装完成后建议立即打开一个全新的命令提示符窗口输入scala -version。这里要注意一定得是新开的窗口因为旧窗口的环境变量是启动时加载的不会自动更新。看到版本信息输出说明安装成功了。2.2 手动部署 zip 包路径完全可控的做法MSI 安装虽然省事但对喜欢掌控一切的人来是有点“黑盒”。如果你不想让安装程序动你的系统环境变量或者你想把 Scala 固定在项目目录里、做多版本并存那么手动下载 zip 包部署是更好的选择。操作步骤很简单。先去 GitHub 上 Scala 官方仓库的 release 页面找到你需要的版本的 zip 文件比如 scala-2.13.16.zip 或 scala3-3.3.6.zip下载后解压到一个固定目录。我个人的习惯是放到 C:\scala\ 下形成 C:\scala\scala-2.13.16\bin 这样的结构。然后只需要做一件事把 bin 目录路径添加到系统环境变量的 PATH 里。打开系统属性 → 环境变量 → 找到 Path 变量 → 编辑 → 新建 → 填入 C:\scala\scala-2.13.16\bin点击确定保存。这种方式的优势在版本切换时特别明显。你可以同时保留 scala-2.13.16 和 scala-3.3.6 两个目录需要哪个版本就改 PATH 指向哪个。如果你的项目既有老的 Spark 代码又想偶尔体验 Scala 3 新语法这种方式比反复卸载重装要舒服得多。2.3 通过 sdkman 管理版本多项目开发者的乐趣第三种方式稍微有点非主流但对于需要在多个 Scala 版本之间频繁切换的开发者来说它是效率最高的。sdkman 本来是一个面向 Unix/Linux 的开发工具版本管理器但它可以通过 Git Bash 在 Windows 上运行前提是你先安装 Git for Windows。装好 Git 之后打开 Git Bash执行curl -s https://get.sdkman.io | bash source $HOME/.sdkman/bin/sdkman-init.sh安装完 sdkman 后用它安装 Scala 就很方便了sdk list scala sdk install scala 2.13.16 sdk default scala 2.13.16sdkman 会把 Scala 装到用户目录下的 .sdkman/candidates/scala/ 里并且自动设置好 PATH。切换版本只需sdk use scala 3.3.6再也不用改系统环境变量了。有一点要提醒sdkman 默认只在 Git Bash 会话里生效。如果你想在 Windows 自带的命令提示符或 PowerShell 里也使用它管理的 Scala需要手动把%USERPROFILE%\.sdkman\candidates\scala\current\bin添加到 PATH 中。这算是不小的限制所以 sdkman 更推荐给已经习惯在 Git Bash 里做开发的人使用。3. 环境变量与构建工具收尾配置3.1 JAVA_HOME 与 PATH 的规范配置安装 Scala 后真正的事故高发区集中在环境变量配置这一步。写具体操作之前先讲明白两件事的区别。JAVA_HOME 是一个约定俗成的环境变量指向 JDK 的根目录比如 C:\Program Files\Eclipse Adoptium\jdk-17.0.10。Java 社区大量工具包括 Scala 的编译器和 sbt在启动时会去读取这个变量用它来定位 java 可执行文件和相关的类库。你不设置它很多工具默认去找系统里的 java 命令一旦系统里装了多个版本的 Java或者 PATH 里的 java 来自 Windows 自带组件的 OpenJDK 文件夹就会发生版本完全不对的怪事。PATH 环境变量则决定了你在命令行里输入一个命令时Windows 去哪些目录里找对应的 .exe 文件。配置 Scala 需要做的就是增加 Scala 的 bin 目录。在 Windows 上建议这样操作右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在“系统变量”区域新建 JAVA_HOME值填写 JDK 安装根目录不带 bin。然后在 Path 变量里增加三样东西%JAVA_HOME%\binscala-2.13.16\bin 的完整路径如果是 sbt 安装的还有 sbt 的 bin 目录配置完成后重开一个命令提示符验证java -version javac -version scala -version如果 java -version 有输出但 javac 提示找不到命令几乎可以肯定是 JAVA_HOME 没有设好或者 Path 里的顺序有问题。javac 和 java 都在同一个 bin 目录里只找到一个说明配置不对。3.2 装完编译器还没结束sbt 的安装与项目初始化很多教程在验证scala -version输出正常后就宣告完成但现实中单纯用 scala 命令手写脚本的场景其实很少绝大多数 Scala 工程都依赖 sbt 来管理依赖和构建项目。所以我的建议是安装完编译器后顺手把 sbt 也装好。sbt 的下载页面提供 Windows 的 .msi 安装包也可以用 zip 包手动部署部署逻辑和 Scala 一样无非是解压加配置 PATH。装好之后在命令行里输入sbt --version一般首次运行会自动下载 sbt 自身的依赖速度看网络情况下载结束后输出版本信息就表示没问题。接着可以用一个官方模板初始化项目sbt new scala/scala3.g8这条命令会从 GitHub 拉取模板并生成一个标准目录结构src/main/scala主代码目录src/test/scala测试代码目录build.sbt构建配置文件在 build.sbt 里指定 Scala 版本时要和前面安装的版本保持一致。例如scalaVersion : 2.13.16然后通过sbt run来编译并运行程序。sbt 第一次启动会下载大量依赖如果网络慢会让人怀疑是不是卡死了实际上它是真的在慢慢拉包。有个经验是配置一个本地依赖加速源减少后续等待时间。具体做法是在用户目录下创建 .sbt/repositories 文件加入可信的公共仓库镜像即可。打个比方别人帮你把依赖提前放到离你最近的地方你下载就快了。这里还有一个容易忽略的细节sbt 启动时分配的内存默认比较保守如果你的机器内存够大可以在 .sbtopts 里设置-J-Xmx2G -J-XX:UseG1GC这样项目编译大依赖时会更流畅。我见过不少人没设置这个跑大型项目时 sbt 一直处于“假死”状态其实是在反复触发 GC。4. 安装验证与高频报错排查4.1 命令行验证与 REPL 实测环境变量配置好之后验证不能只停留在scala -version我建议你做一次完整的小流程测试确认编译器、类库路径和 JVM 都能正常工作。第一验证 REPL交互式解释器。在命令行输入scala进入 Scala 交互环境然后输入val nums (1 to 10).filter(_ % 2 0).map(_ * 2) nums.foreach(println)如果能看到 4、8、12、16、20 的输出说明 REPL 能正常解析表达式、调用标准库整个 Scala 运行时链路是通的。第二验证 scalac 的手工编译。写一个最简单的文件 Hello.scalaobject Hello { def main(args: Array[String]): Unit { println(Hello Scala on Windows) } }然后执行scalac Hello.scala这一步会生成 Hello.class 和 Hello$.class 两个字节码文件。再执行scala Hello如果正常打印字符串说明从编译器到 JVM 执行整条流水线没问题。这个过程也是理解 Scala 编译原理很好的切入点编译器生成的是和 Java 几乎一样的 class 文件最终由 JVM 解释执行。第三如果你装 sbt 了跑一个sbt run看看构建工具能否正常拉取依赖。这一步通过的话说明你后续开发的路基本畅通了。4.2 常见报错与解决思路排查报错时下面的表格是我最常遇到的几种对照着检查能省很多时间。症状可能原因解决思路提示“scala 不是内部或外部命令”PATH 没配好或配置后没开新窗口检查 PATH 里的 bin 路径重开终端窗口提示“错误: 找不到或无法加载主类 scala.tools.nsc.Main”JAVA_HOME 指向了 JRE 而不是 JDK或 Scala 安装不完整检查 JAVA_HOME重装完整 JDK提示“无法定位 JAVA_HOME”根本没设置 JAVA_HOME 环境变量设置 JAVA_HOME 指向 JDK 根目录编译时报“Unsupported class file major version”当前 JDK 版本过新Scala 编译器太旧不支持升级 Scala 版本或换用兼容的 JDKREPL 里中文字符乱码Windows 控制台默认编码与 UTF-8 冲突在控制台执行chcp 65001切换 UTF-8 编码sbt 首次启动长时间没反应需要下载大量依赖包网络不稳定配置可靠的镜像仓库设置 .sbtopts 加大内存先说“scala 不是内部或外部命令”这个最常见的问题。这是典型的 PATH 没有生效。Windows 的环境变量在每条新命令窗口启动时才会读取一次如果是配置环境变量之前就打开的终端你在这个终端里怎么折腾都不会生效。解决办法就是关掉所有命令提示符窗口重新打开一个新的。如果开了新窗口还是不行重点检查你加的路径对不对特别是确认 bin 目录的位置。很多人把路径加到了 Scala 解压根目录细节很重要。再说“找不到或无法加载主类 scala.tools.nsc.Main”这种报错它往往比 PATH 问题更隐蔽。scalac 在启动时需要找到 Scala 编译器的核心类库这些类库通常位于 lib 目录下。如果 JAVA_HOME 指向的是 JRE 而不是 JDK编译器会无法定位某些工具链中的类于是报出这个错误。解决办法很简单确认 JAVA_HOME 一定指向 JDK 根目录而不是 JRE。另外如果你机器上装了多个 JDK 版本最好把不需要的版本卸掉或者保证 JAVA_HOME 和 PATH 里的 java 命令指向同一个版本。“Unsupported class file major version”这个报错多见于老编译器配新 JDK。JDK 新版本编译出来的 class 文件的 major version 会递增旧版 Scala 编译器不认识就直接罢工了。比如 Scala 2.12 老版本遇到 JDK 17 就会这样。处理方式有两种要么把 Scala 升到支持新 JDK 的版本要么把 JDK 降到 8 或 11。做大数据开发时我建议第二种因为很多老版本的 Spark 组件对 JDK 版本更敏感。REPL 中文乱码的问题也是 Windows 特有的麻烦。新版 Scala REPL 默认按 UTF-8 处理字符但 Windows 命令提示符的默认代码页可能是 GBKcp936两边编码对不上中文输入输出就会变成一堆乱码。临时解决办法是在命令行执行chcp 65001把代码页切到 UTF-8长期来看我建议直接用 Windows Terminal 替代旧版命令提示符它对 UTF-8 的支持明显更友好。4.3 一个容易踩的隐藏坑环境变量里的路径空格前面我反复提过安装目录尽量别带空格这里展开说下原因。Scala 编译器本身能处理带空格的路径但许多配套工具不行。比如你如果在 PowerShell 里执行一条复杂的命令行路径空格会破坏参数解析又比如你在代码里调用了外部进程去加载某个类路径带空格的中文路径都可能导致加载失败。如果你已经装在 Program Files 里了怎么办建议直接把 Scala 目录移动到一个无空格路径下比如 C:\scala\然后改一下 PATH。你会发现后续少很多莫名其妙的兼容性问题。这属于一次整理、长期受益的操作。5. 关于 Spark、Elasticsearch 等生态工具的连带提醒装好 Scala 的人通常不是单纯为了学语言更多是为了跑大数据生态里的工具链。这里单独开一节说一下 Scala 版本和生态工具之间的关系算是把前文提到的选型问题的延伸。如果你装 Scala 是为了 Spark那么记住一个原则Spark 的版本和 Scala 的版本必须匹配。Spark 3.3 及之前版本基于 Scala 2.12 构建从 Spark 3.4 开始提供了对 Scala 2.13 的支持。当你用 sbt 建工程时build.sbt 里的 scalaVersion 必须写成和 Spark 对应版本一致的那个大版本否则会下拉依赖失败。这一点每年都能看到不少初学者踩坑。Elasticsearch、Kafka 这些工具有些读者可能也会一起接触。需要说明的是Elasticsearch 本身是 Java 技术栈不直接依赖 Scala但很多围绕 ELK 生态写的辅助工具或日志处理脚本可能会在实际操作中顺带使用 Scala。这种情况下 Scala 装好后JDK 版本反而更重要——Elasticsearch 8.x 通常要求 JDK 17 及以上。如果你同时要跑 Spark 和 Elasticsearch一个稳妥的组合是 JDK 17 Scala 2.13 兼容版本的 Spark这样两边的需求都能覆盖。还有人会通过 Windows 上的 Docker Desktop 跑这些组件的容器。Scala 本身安装在 Windows 宿主机还是在 Linux 容器里两者并不冲突完全可以在宿主机装一套 Scala再用容器跑 Elasticsearch 或 Redis 这些有独立镜像的服务。唯一的建议是装 Docker Desktop 时开启 WSL2 后端资源占用更低启动速度也更快Java 生态的工具在里面跑起来比老的 Hyper-V 后端顺畅不少。最后的实操心得把整个安装流程走完一遍我再分享几个自己长期实践下来的小建议。第一装完 Scala 之后马上建一个 sbt 工程跑一遍sbt run不要只停留在scala -version这一步。sbt 是 Scala 开发绕不开的构建工具第一次启动会暴露绝大部分环境问题与其等要用的时候再来排查不如装完就把它跑通。第二JDK、Scala、构建工具这三样东西的版本关系一定要记牢。JDK 和 Scala 是双向兼容的不是所有 Scala 版本都支持所有 JDK 版本。遇到怪异报错时先把版本组合列出来排查远比重装软件有效。第三如果是在 16GB 内存以上的开发机上记得给 sbt 配足内存。很多人反映 Scala 项目编译慢其实有一部分原因是默认内存太小导致频繁 GC 而不是真正在编译。修改 .sbtopts 里-J-Xmx参数能让你日后的开发体验提升非常明显。Windows 上装 Scala 的坑基本都在版本和环境变量这两块只要把选型和路径配置一次搞对后面的开发流程其实是相当顺滑的。希望这篇记录能帮你少走我当年走过的弯路。