企业官网建设流程全解析

不少人拿到一台装了 Linux 的机器，第一反应就是赶紧去 Scala 官网下载 tar.gz 包，解压完配上 PATH 就开始跑代码。这个思路本身没错，但我在实际帮同事排障的过程里，见过太多因为前期疏忽多花半小时的情况——要么 JDK 版本太低，跑起来直接 UnsupportedClassVersionError；要么 PATH 写错位置，shell 怎么都找不到 scala 命令；要么下载包和 CPU 架构不匹配，装完一脸懵。这篇就把我在 Linux 上安装 Scala 的完整过程、版本踩坑记录和常用验证命令都捋一遍，保证你能从零装好、跑起 REPL、写完第一个脚本编译运行，一步到位。

如果看完你只想记一句话，那就是：先装对 JDK，再选对安装方式，最后配环境变量必须理解原理。下面具体展开。

1. 安装前的准备：把环境理清楚再动手

1.1 先确认你的发行版、架构和磁盘空间

很多人一上来就下载安装包，这是第一个坑。Scala 本质上是一组 JVM 字节码工具，它对系统底层的依赖不像 C 语言程序那么强，但你的 Linux 发行版决定了你用哪种方式管理 JDK 和安装包，CPU 架构决定了你要下载哪个版本的二进制压缩包。

先用几条基础命令把家底摸清楚：

cat /etc/os-release # 查看发行版信息，比如 Ubuntu 22.04、CentOS 7 等 uname -m # 查看 CPU 架构，x86_64 是常见的 Intel/AMD 64位，aarch64 是 ARM 64位 free -h # 查看内存大小 df -h /opt # 查看 /opt 目录所在分区的可用磁盘空间

为什么要看这些？因为 Debian 系的 Ubuntu/Debian 用apt管理软件包，Red Hat 系的 CentOS/RHEL 用yum或dnf，后面安装 JDK 时的命令完全不一样。架构也重要：现在越来越多的服务器是 ARM 芯片，如果你在官网下载时选错了 tar.gz 包，装在 aarch64 机器上通常不会直接报“架构不对”，而是会在后续跑 java 或 scala 命令时出现各种诡异异常。内存方面，Scala 编译器scalac在编译大项目时比较吃内存，低于 2G 内存的机器建议不要开太多其他服务，免得编译到一半 OOM。

至于磁盘空间，Scala 发行包本身两三百兆，但 JDK 加上后续你难免要装 sbt、IDE 等工具，建议/opt下的可用空间至少留 5G 以上，别只看当前那一个包的大小。

1.2 为什么必须先装 JDK：Scala 是跑在 JVM 上的

很多人把 Scala 叫“一门语言”，但它更准确的说法是“JVM 上的一套语言和工具链”。Scala 源码会被编译成 JVM 字节码，然后由 JVM 执行。编译器scalac本身也是一个 Java 程序，所以你的机器上必须先有 JDK（Java Development Kit），才能跑 Scala。

这里有一个非常关键的点：不同的 Scala 版本对 Java 版本的要求不一样。如果你闭着眼睛装了个最新版 JDK，或者只装了 JRE（Java Runtime Environment），很容易在安装后第一行代码就翻车。

我整理过一张简表，建议直接按这个选型：

如果你是在 2024 年后新装 Scala，我的建议是Scala 3 搭配 OpenJDK 17。Scala 3 是当前长期演进的主线版本，语法更简洁，官方支持力度大，JDK 17 也是一签名 LTS 版本，两个配合起来既稳定又能用到新特性。如果你因为历史项目必须用 2.13，那至少把 JDK 装到 11 以上，避免未来升级库时被版本卡脖子。

在 Ubuntu/Debian 系上安装 OpenJDK 17：

sudo apt update sudo apt install -y openjdk-17-jdk

装完后执行验证：

java -version

正确的输出应类似：

openjdk version "17.0.10" 2024-01-16 LTS OpenJDK Runtime Environment (build 17.0.10+7) OpenJDK 64-Bit Server VM (build 17.0.10+7, mixed mode, sharing)

如果你的系统上曾经装过多个 Java 版本，可以用update-alternatives来切换默认版本：

sudo update-alternatives --config java

这一步能避免后续你明明装了 JDK 17，但java -version却显示 1.8 这种尴尬情况。JDK 装不对，后面 Scala 百分之百跑不起来。

2. 三种安装方式怎么选：手动、包管理器、SDKMAN

2.1 从官网下载 tar.gz 手动安装

手动安装最大的优势是“可控”和“与发行版无关”。你在 Ubuntu 上摸索出来的安装流程，换到 Debian、CentOS 甚至某些国产 Linux 发行版上，大概率也能复用，因为本质就是解压、配 PATH 两步。

缺点是升级麻烦。以后要换版本，你得自己重新下载、解压、改环境变量，版本切换全靠手动。如果你只是偶尔写写脚本、不搞 Scala 项目，手动安装其实够用了。

Scala 2.13 的稳定版可以从下面的地址获取，历史版本都按版本号放好了：

https://downloads.lightbend.com/scala/2.13.14/scala-2.13.14.tgz

Scala 3 的发布包则主要在 GitHub Releases 页面管理，下载后注意核对文件名里的版本号和架构标记。你在浏览器里打开官网 ScaLang，点 Download 按钮时要注意区分“Scala 2”和“Scala 3”的下载链接，别下错。

2.2 用 APT 等发行版包管理器安装：看起来省事但版本很旧

Debian/Ubuntu 自带软件源里确实有 Scala 包，安装命令也简单：

sudo apt install -y scala

但我必须直说：不推荐这么干。各大发行版的软件源更新有滞后性，很多源里的 Scala 还停留在 2.11 甚至更老的版本。2.11 这个版本已经太老了，新一代 Scala 库大部分不再兼容。你装完可能发现连scala.util.Using这类常用 API 都没有，体验极差。

所以我的建议是：包管理器安装这个选项，只适合“临时给某台服务器补个 Scala 环境应急看一眼”的场景，真正要长期开发，别省这个事。

2.3 用 SDKMAN 管理多个版本：我个人的首选

如果你打算在 Linux 上长期写 Scala，我最推荐的方式是SDKMAN。它是一个命令行工具，能统一管理 Java、Scala、sbt、Kotlin 等 JVM 系工具的多个版本，切换版本只要一条命令。

安装 SDKMAN 本身很容易：

curl -s "https://get.sdkman.io" | bash

执行完毕后，需要让当前 shell 加载它的初始化脚本：

source "$HOME/.sdkman/bin/sdkman-init.sh"

然后查看可用的 Scala 版本：

sdk list scala

安装指定版本：

sdk install scala 3.3.1

安装完成后，SDKMAN 会自动把当前用户环境切换到刚装好的版本。你再次打开终端敲scala -version，就能直接看到 3.3.1。想切换版本：

sdk default scala 2.13.14

或者只是当前终端临时用某个版本：

sdk use scala 2.13.14

这里要说明一个技术细节：SDKMAN 的版本切换是基于修改PATH环境变量的，它会在你的~/.sdkman/candidates/scala/current和具体版本目录之间建软链，然后把$SDKMAN_DIR/candidates/scala/current/bin提前到 PATH 里。这套机制对你系统全局的配置影响很小，比手动安装改/etc/profile干净得多，也容易卸载。

2.4 还有一条新路线：Coursier

这几年 Scala 社区里越来越多人用Coursier来管理环境。它可以一条命令装 JDK、Scala、sbt，非常适合刚从零搭建开发机。

curl -fL "https://github.com/coursier/coursier/releases/latest/download/cs-x86_64-pc-linux.gz" | gzip -d > cs chmod +x cs ./cs setup

cs setup会自动检查并安装 JDK（按需选择版本）、Scala 和常用工具，然后配置好 PATH。不过它对新手来说有点“黑盒”——装完你不太清楚文件都放在了哪里。所以我把它放在备选方案里，等你有一定经验后再用也不迟。

三种方式怎么选？我的结论如下表：

3. 一步步手动安装：下载到配置环境变量的全过程

下面给一套完整的手动安装操作，目标是装一个Scala 2.13.14 配合 JDK 17。其实这套流程适用于任何 tar.gz 发布包，你只要把版本号替换成你想装的即可。

3.1 下载安装包并核对校验值

先用变量把版本号固定下来，方便后面复用：

SCALA_VERSION=2.13.14

下载到/tmp目录：

wget -P /tmp "https://downloads.lightbend.com/scala/${SCALA_VERSION}/scala-${SCALA_VERSION}.tgz"

如果你在的区域访问这个 CDN 不稳定，可以尝试从 GitHub Releases 下载，效果类似。

下载完建议做一步校验。去官网或 GitHub Release 页面找对应该文件 SHA-256 哈希值，然后：

sha256sum /tmp/scala-${SCALA_VERSION}.tgz

把输出值和官网的值对比一下，一致再继续。这一步能避免下载了损坏的包。我见过有人跳过这步，结果 tar 解压时报错，浪费了几分钟才意识到问题。

3.2 解压并把 Scala 安装到 /opt/scala

通常这类开发工具推荐放在/opt目录下，这个目录本来就是用来放第三方应用包的。用sudo建目录、解压、移动：

sudo tar -xzf /tmp/scala-${SCALA_VERSION}.tgz -C /opt

这一步其实已经完成了百分九十的安装——解压出来的文件自带bin/scala、bin/scalac等可执行脚本。但我们还不能直接用，原因是 shell 的 PATH 里没有指向它们的条目。

你可以先看一眼解压后的目录结构：

ls /opt/scala-${SCALA_VERSION}/bin

正常情况下你会看到这些可执行文件：scala、scalac、scaladoc、scalap。

顺带解释一下这几个命令的用途：scala负责启动 REPL 或运行编译后的字节码，scalac负责把.scala源码编译成.class字节码文件，scaladoc负责生成 API 文档。后面编译脚本时我们会用到scalac。

如果你希望以后升级时不残留旧版本，可以在/opt下建一个不带版本号的软链：

sudo ln -s /opt/scala-${SCALA_VERSION} /opt/scala

这样环境变量里始终指向/opt/scala，升级新版本时只需替换软链，不用反复改配置。

3.3 配置环境变量：理解 PATH 和 SCALA_HOME

这是整个手动安装过程中最核心、最容易出错的一步。很多人把环境变量配错，是因为不理解 shell 启动时加载哪些文件。

我们通常把当前用户的环境变量写进~/.bashrc，因为每次打开新的交互式终端，bash 都会重新读取这个文件。用编辑器打开：

vim ~/.bashrc

在文件末尾追加：

export SCALA_HOME=/opt/scala export PATH=$SCALA_HOME/bin:$PATH

这里解释一下两行配置各自的角色：

• SCALA_HOME是给某些工具或脚本用的约定变量，表明 Scala 的安装根目录。虽然 Scala 本身的脚本不一定依赖它，但是 sbt、IDE 等工具经常会读取这个变量，所以建议保留。
• 第二行是把$SCALA_HOME/bin添加到 PATH 的最前面。注意这里用的$PATH必须放在后面，如果你写反了，写成了export PATH=$PATH:$SCALA_HOME/bin，其实也能用，但如果系统里存在同名命令，系统会优先执行前面的旧命令，可能不小心踩坑。

保存并退出后，让配置立即生效：

source ~/.bashrc

现在验证：

scala -version

如果输出类似下面的信息，说明安装成功：

Scala code runner version 2.13.14 -- Copyright 2002-2022, LAMP/EPFL

这里有几个容易出错的分支情况，我顺便提一下：

• 如果你用的是 zsh，应该编辑~/.zshrc而不是~/.bashrc；
• 如果你用的是 fish shell，语法不同，需要用set -gx；
• 如果你希望所有用户都能用，可以把 export 写入/etc/profile.d/scala.sh这样的全局配置文件，但这通常需要 root 权限，个人开发机没这个必要。

3.4 跑一个最小可执行命令确认环境

环境变量配好后，先跑个最简单的：

scala -e 'println("Hello from Scala")'

-e参数可以直接执行一行代码。如果输出Hello from Scala，那说明 JDK 版本匹配、PATH 配置正确、Scala 编译器能正常启动。这一步是整个安装流程的“破冰验证”，比验证scala -version更能反映实际问题——因为-version只是打印版本字符串，不涉及类加载和 JVM 启动的完整链路。

4. 装完之后常见问题与排查实录

4.1 scala: command not found

这是最简单但也最普遍的报错。先别慌，按顺序排查：

echo $PATH

看输出里有没有刚开始配置的/opt/scala/bin。如果没看到，说明环境变量没生效，回到第 3.3 节，确认你是否编辑了正确的启动文件，并且执行了source。

如果 PATH 里有/opt/scala/bin，但依然提示找不到命令，那大概率是软链失效或者目录不存在：

ls -l /opt/scala

如果显示目录不存在或软链红链，重建软链并重新source即可。

4.2 java.lang.UnsupportedClassVersionError 的排查办法

你刚装好 Scala，一跑scala -version或编译某段代码，弹出这样的异常：

java.lang.UnsupportedClassVersionError: scala/tools/nsc/Main has been compiled by a more recent version of the Java Runtime ...

这句话翻译成人话：Scala 编译器的字节码版本高于当前 JVM 能识别的版本。比如你装了 Scala 2.13.14（默认目标 Java 11），而系统JAVA_HOME指向的是 JDK 8，就会这样。

解决办法是确保当前 shell 里的JAVA_HOME指向正确的 JDK：

echo $JAVA_HOME

如果没有输出，你需要找到 JDK 17 的安装路径，常见路径是/usr/lib/jvm/java-17-openjdk-amd64。然后在~/.bashrc里增加：

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 export PATH=$JAVA_HOME/bin:$PATH

再source ~/.bashrc，重新验证。

如果你系统里安了多个 JDK，也可以直接用update-alternatives切换：

sudo update-alternatives --config java

这个UnsupportedClassVersionError在我踩过的坑里出现频率极高，而且它不一定出现在第一秒——很多人在装完 Scala 之后过了一周，因为切换 JDK 版本突然报这个错，所以遇到它优先查 JAVA_HOME，准没错。

4.3 版本串台：我装的明明是 Scala 3，怎么跑起来是 2.12？

如果你的机器上曾经用过 SDKMAN、Coursier 或手动安装过其他版本，很容易出现which scala指向的不是你期待的那一个。排查命令：

which scala scala -version

which scala会告诉你实际执行文件的路径。如果你手动安装的路径是/opt/scala/bin/scala，但which返回/usr/bin/scala，说明 PATH 里/usr/bin排在/opt/scala/bin前面，系统优先找到了旧版。

解决方法是调整 PATH 顺序，或者在~/.bashrc里把/opt/scala/bin放到更靠前的位置。这也是我前面为什么强调$PATH要放在后面的原因——把新配置的 bin 目录放在前面，能避免系统跟旧命令“串台”。

4.4 权限问题：用 sudo 装的路径普通用户不能用

有两个典型场景：

场景一：你把/opt/scala里的文件所有权搞乱了。如果你用sudo tar解压，目录属于 root。普通用户虽然可以读取和运行，但如果你想在/opt/scala下写文件或做升级，就会遇到Permission denied。一般运行 Scala 代码不需要写安装目录，所以问题不大，但如果你后续要用 SDKMAN 管理版本，它会尝试在/opt附近创建软链，就会失败。建议普通用户用 SDKMAN 时安装到自己家目录的~/.sdkman下，不要用 sudo。

场景二：你图省事用sudo scala跑代码，结果写出来的文件都归 root，后面操作得很别扭。不建议随手 sudo 运行 Scala 命令，除非你真的需要管理 /opt 目录。

4.5 下载慢或总是失败

官网下载慢是常态。如果遇到超时，可以：

• 先 ping 一下域名，确定是不是网络不稳定；
• 换用 GitHub Releases 下载，通常更稳定；
• 配置国内镜像源。部分高校和云厂商维护着 Scala 相关组件镜像，对于 tar.gz 发布包，最稳妥的还是用镜像站的 sbt、Maven 仓库来替代，下载安装包本身找 GitHub 会比官网更容易续传。

也可以在 wget 后面加-c参数支持断点续传：

wget -c "https://downloads.lightbend.com/scala/2.13.14/scala-2.13.14.tgz"

4.6 sbt、IDE 不认你装好的 Scala

有时候命令行里scala -version正常，但一打开 IntelliJ IDEA，新建 Scala 项目却找不到 Scala 库。这是因为 IDE 不直接使用命令行 PATH，它自己维护一份 JVM 和 Scala 的配置。你在 IDEA 里需要手动指定：File -> Project Structure -> Global Libraries，添加 Scala SDK 时选择/opt/scala目录。IDEA 会读取对应目录下的 lib 文件夹，识别出版本。如果识别失败，可以检查目录完整性，重新建立软链试试。

5. 验证安装并写下你的第一个 Scala 程序

5.1 进 REPL 试运行

Scala 自带一个交互式解释器（REPL），类似 Python 的交互模式。安装成功后，直接输入scala回车，你会看到提示符：

scala>

在这里可以输入表达式，回车立即出结果。比如：

scala> val greeting = "Hello, Scala" scala> println(greeting)

REPL 是验证环境是否可用的最快方式。如果你能进入提示符并执行 println，说明 Scala 运行时、JVM、类库链路都正常。初学者建议多在这里面玩一玩语法，不用急着写复杂文件。

5.2 编写 hello.scala 并编译运行

我推荐用这个例子来验证编译链路。创建一个hello.scala文件：

mkdir -p ~/scala-test cd ~/scala-test vim hello.scala

写入以下内容：

object Hello { def main(args: Array[String]): Unit = { println("Hello, Scala from Linux!") } }

这是一个最简单的 Scala 入口点。注意这里的object Hello不是 class，Scala 用单例对象来承载main方法。这和 Java 的public class Hello写法有差异。

编译：

scalac hello.scala

编译成功后，当前目录下会出现几个.class文件，其中就包括Hello.class。然后运行：

scala Hello

输出：

Hello, Scala from Linux!

到这里，你的 Scala 环境算是彻底能干活了：能编译、能运行、命令行链路完整。

也可以直接一行运行（不经过 scalac）：

scala hello.scala

scala命令会直接执行脚本文件，适合快速验证小代码片段。但对大的项目，标准流程依然是scalac编译成字节码再运行，因为可以拿到更好的编译期检查和性能。

5.3 把 Scala 接入 IDE：IntelliJ IDEA 配置要点

如果你不满足于命令行，你多半会在 IDE 里写。目前 IntelliJ IDEA 对 Scala 的支持最成熟，安装步骤大体是：

1. 安装 IntelliJ IDEA Community 或 Ultimate 版；
2. 打开插件市场，搜索 Scala 插件并安装；
3. 新建 Scala 项目，选择 JDK（这里选你已经装好的 JDK 17）；
4. 选择 Scala SDK，如果没自动识别，手动选择/opt/scala或/opt/scala-2.13.14；
5. 项目建好后，IDE 会自动帮你管理编译和运行。

这里我要提醒一个细节：IntelliJ IDEA 自己会带一个内置的 JBR（JetBrains Runtime），它跟系统 JDK 不一定相同。当 IDEA 里新建项目时，务必在 Project SDK 下拉框里选你希望使用的 JDK 17，否则可能出现 IDEA 能编译、但命令行里scala跑不了同一个项目的情况。这就是我反复强调“JDK 版本一致性”的原因。

5.4 把 Scala 接入 sbt 构建工具

如果你准备写一个真正意义上的项目，建议上 sbt。sbt 是 Scala 社区最常用的构建工具，类似 Java 世界的 Maven/Gradle。

安装 sbt 最省心的方法是用 SDKMAN：

sdk install sbt

然后在项目目录里创建build.sbt：

ThisBuild / scalaVersion := "2.13.14" lazy val root = (project in file(".")) .settings( name := "hello-sbt", version := "0.1.0" )

接着执行：

sbt compile sbt run

sbt 首次启动会下载大量依赖到~/.ivy2和~/.cache/coursier，网络差时可能要等几分钟，这是正常现象，不是卡住了。如果你在国内，建议给 sbt 配置阿里云或华为云的 Maven 镜像，方式是在~/.sbt/repositories文件里写好镜像地址。这个文件内容类似：

[repositories] local aliyun-public: https://maven.aliyun.com/repository/public aliyun-central: https://maven.aliyun.com/repository/central

具体细节不同版本略有出入，但思路就是让 sbt 优先走镜像仓库。

6. 装好之后还能做点什么：提升日常使用体验

6.1 用 SDKMAN 一键管理多个版本之后，别忘了常用命令

SDKMAN 安装完之后，有几个高频命令值得记住：

sdk list java # 查看所有可用 JDK 版本 sdk list scala # 查看所有可用 Scala 版本 sdk install java 17.0.10-tem # 安装 Temurin JDK 17 sdk default scala 3.3.1 # 设置全局默认 Scala

我个人的习惯是：系统全局默认装一个稳定版 Scala 3，但每个项目必要时在sdk use scala 2.13.14临时切到旧版。这样既不会因为版本切换破坏环境，也不需要在多个 tar.gz 包里手动切 PATH。

要注意，SDKMAN 的current软链是有状态的，如果你是多个用户共用一台机器，建议大家都用自己的 shell 配置文件，别指望系统级的环境变量能统一管理。

6.2 善用 Ammonite 增强 REPL

Scala 自带的 REPL 能用，但体验称不上好。如果你想在日常写小片段时更顺手，可以试试 Ammonite，它是一个增强版 Scala REPL，支持语法高亮、补全、更友好的错误提示。

安装很简单：

curl -s https://ammonite.io/2.13.14/ammonite-2.13.14-2.5.9 | sudo tee /usr/local/bin/amm > /dev/null sudo chmod +x /usr/local/bin/amm

然后运行：

amm

装过之后你会发现实际写代码的幸福感提升不少。不过这属于“增强体验”而非“必需”，初学阶段直接用自带的 REPL 就够了。

6.3 别忘了 scalac 的常用编译参数

很多新人以为scalac只能直接编译整个文件，其实它和 javac 类似，支持很多参数。我常用这几个：

scalac -deprecation hello.scala # 输出使用了废弃 API 的警告 scalac -feature hello.scala # 输出使用了语言特性的提示 scalac -encoding utf-8 hello.scala # 指定源码编码

如果你把 Scala 源码文件存为 UTF-8 格式，而系统区域设置是 POSIX 或 C，不指定-encoding时中文注释和字符串可能乱码或编译报错。加上这个参数能避免很多隐性麻烦。

6.4 升级 Scala 版本的迁移注意事项

未来你肯定要面对升版的问题。从 2.13 升到 Scala 3，不完全向下兼容：很多宏、隐式转换写法在 Scala 3 里需要调整，部分库也要换成适配版本。从 2.12 升到 2.13 相对平缓，主要是一些标准库 API 的废弃和移除。

我个人建议的升级路径是：先在 SDKMAN 里安装新版本，再创建一个临时分支用sbt clean compile跑一遍整个项目，看看哪里报错。不要在旧环境上直接改版本号，否则依赖冲突信息会淹没你，基本没法定位。

6.5 定期检查环境变量是否有冗余

装过几次 Scala、JDK 之后，~/.bashrc里可能会出现很多重复的 export。比如我曾经见过一份文件里同时写了三个 JAVA_HOME 的导出，后面的不会覆盖前面的，因为 bash 按顺序执行，最后一个生效。但如果哪天你调整了顺序，就会突然发现 JDK 版本变了。所以定期检查一下配置文件是值得的：

grep -n "SCALA_HOME\|JAVA_HOME\|PATH=" ~/.bashrc

保持环境变量简洁，能少掉很多玄学问题。

回到开头那个问题：在 Linux 上安装 Scala，到底难不难？我的答案是：如果你理解了“Scala 需要 JVM”“PATH 决定命令查找顺序”“Scala 版本对 JDK 有要求”这三件事，整个过程其实非常顺。如果非要再分享一个经验，那就是不要把所有步骤都交给“一键脚本”而完全不懂原理。SDKMAN 和 Coursier 确实方便，但万一出了问题，你知道它改了什么、文件放在哪里，才能真正定位解决。装环境这种事，麻烦一次，搞清楚底层逻辑，之后换版本、升 JDK、换机器都能应对自如。