企业官网建设流程全解析

前阵子帮朋友收拾一台好久没动的 Linux 服务器，准备把默认的 Java 从老版本切到新装的 JDK。我本来以为这事很简单，改改 PATH 顺序就行，结果敲javac -version一查，PATH 里排在前面的那个版本根本没生效。后来才反应过来，这台机器用的是 dpkg 体系的发行版，/usr/bin/java这类公共命令早就被一套叫 alternatives 的符号链接管理机制接管了，真正决定“默认用哪个版本”的，是/etc/alternatives目录里的链接，以及它的管理命令update-alternatives。

这篇内容我打算把 alternatives 的底层思路、日常高频命令、几个典型切换场景、容易踩的坑，还有怎么给自己用的工具链手工建一套 alternatives 组，全部梳理一遍。无论你是刚接触 Linux 命令行的新手，还是已经在服务器上部署过多个运行时版本的老手，只要遇到“同一个命令装了多个版本想切换默认值”的需求，这套机制都是绕不开的基础功。

1. 先拨开迷雾：alternatives 到底在系统的哪个位置插手了

说到底，alternatives 解决的是一个非常朴素的问题：系统里可能有多个软件包都提供同一个命令，比如各种编辑器都提供editor，多个 JDK 都提供java，多个编译器都提供gcc。如果每个包安装时都直接往/usr/bin/java写自己的程序，后装的会把先装的覆盖掉，卸载时又说不清这个文件该不该删。于是就有了一个“中间人”角色。

这个中间人的物理形态其实是一串符号链接。拿 Java 举例，正常情况下你执行java，实际经过的链路是：

/usr/bin/java -> /etc/alternatives/java -> /usr/lib/jvm/某个JDK/bin/java

第一跳/usr/bin/java指向/etc/alternatives/java，第二跳/etc/alternatives/java再指向具体的 JDK 路径。/usr/bin下这层链接是给用户和 shell 用的，真正随时可能被切换的是/etc/alternatives/java这条。这样设计的好处是，不管背后注册了三个还是五个 JDK，对外暴露的/usr/bin/java始终只有一个稳定入口，切换动作在中间层完成，不会把/usr/bin下的文件改得乱七八糟。

1.1 组、主链接和从链接

在 alternatives 的世界里，一组相关链接统称一个“组”。每个组至少有一个主链接，也就是/usr/bin/java对应的那个java组。主链接的命名通常比较简短，比如java、editor、gcc，它并不等于完整路径，而是作为组的 ID 存在。命令里你会反复看到update-alternatives --config java这种写法，这里的java指的就是组名。

除了主链接，一个组还可以挂若干从链接，术语叫 slave link。继续拿 JDK 举例：你切换java的时候，通常也希望javac、jar、javadoc这些配套命令跟着一起切到同一套 JDK，否则很可能出现java是 17 而javac还是 8 的尴尬局面。这些配套命令就可以通过--slave参数挂到同一个组里，切换主链接时，从链接会自动跟着切换。

1.2 auto 和 manual：两种容易混淆的状态

每个 alternatives 组都处于两种模式之一：自动模式（auto）和手动模式（manual）。

自动模式的意思是，系统根据候选的优先级自动决定当前生效的路径，谁的优先级数字大谁就生效。你新注册了一个优先级更高的候选，系统会立刻把链接切过去。手动模式则相反，你用--config或--set明确指定了某一个候选后，即使后面来了优先级更高的新候选，系统也不会自动切换，而是保持你选择的结果。

为什么要区分这两种状态？我自己的理解是，它能平衡“包管理器自动维护”和“用户显式意图”之间的矛盾。包安装默认是 auto，升级时可能自动切到更好的版本；但如果你因为某种兼容性需要强制锁定某个旧版本，manual 模式就能保证系统不会自作主张。这个设计在后续排查问题时会反复用到。

1.3 配置存在哪里

这些状态不是存在内存里的，而是落在文件系统上。/etc/alternatives/目录里全是真实的符号链接，也就是你系统当前生效的那一层。另一处是/var/lib/dpkg/alternatives/，里面保存着每个组的具体配置：组名、模式、公共链接路径、候选列表、各自的优先级。这个目录里的文件默认不需要手工编辑，但也值得知道它的存在——有人手欠直接改了这里，结果包管理器一升级就全被覆盖，属于典型的白忙活。

2. 从新增到移除：一表摸清 update-alternatives 的日常命令

理解了“组”和“链接链”这两个概念之后，命令就好记多了。因为无论查看、切换、新增还是移除，你操作的核心对象始终是“某个组”。我把日常最高频的几个操作整理成一张表，方便对照着用。

绝大多数操作都需要 root 权限，所以实际敲命令时几乎都要在前面加sudo，这一点和普通文件操作不太一样，别心存侥幸。

2.1 注册候选时那四个参数分别是什么意思

以手动注册一个 JDK 为例：

sudo update-alternatives --install /usr/bin/java java /opt/jdk-17/bin/java 1700

第一个参数/usr/bin/java是公共链接的路径，也就是用户最终敲击的命令入口。第二个参数java是组名。第三个参数/opt/jdk-17/bin/java是这个候选实际指向的程序路径，必须真实存在。最后一个1700是优先级，数字越大越优先。

这里容易有人犯迷糊：公共链接和组名看着很像，为什么不直接写一个？我的理解是，公共链接路径是给系统创建/usr/bin/java用的，组名则是为了在/etc/alternatives下生成同名链接，还要在/var/lib/dpkg/alternatives里对应一个状态文件。把这两个概念分开，才能支持“一个命令对应多个组入口”这样更灵活的场景。实际中绝大多数情况都写成同名，理解就好。

2.2 查看当前状态该看哪几个关键字段

执行update-alternatives --display java时，输出看起来大致是这样：

java - auto mode link currently points to /usr/lib/jvm/java-17/bin/java /usr/lib/jvm/java-17/bin/java - priority 1700 /usr/lib/jvm/java-8/bin/java - priority 1081 Current 'best' version is '/usr/lib/jvm/java-17/bin/java'.

重点是看link currently points to这一行，它表示当前真正生效的路径。如果状态是 manual，你还会看到manual mode字样，这意味着即使存在优先级更高的候选，系统也不会自动切过去。排查“为什么没切过来”的时候，这一步能帮你省下大半时间。

如果你需要把这个状态喂给脚本，比如写 CI 或巡检逻辑，那更适合用update-alternatives --query java。它的输出结构比--display更适合解析，关键字段是Value:，对应的就是当前实际生效的候选路径，而且不会夹杂给人看的人类语言。

3. 真实案例：把 Java、编辑器、编译器都切到想要的默认版本

光说命令不够直观，我拿三个最常见的场景来演示。大家遇到 alternatives 基本都是在这几类需求里打转。

3.1 案例一：Java 多版本切换

服务器上可能有系统包管理器装的 OpenJDK，也可能有人手工解压了一个 JDK 到/opt。这时候最稳妥的方法不是改 PATH，而是注册成 alternatives 候选。

先看看当前有哪些候选：

sudo update-alternatives --list java

如果看到两个路径，比如/usr/lib/jvm/java-17/bin/java和/usr/lib/jvm/java-8/bin/java，直接切换：

sudo update-alternatives --config java

它会打印一个带编号的菜单，输入数字回车即可。如果手工解压的 JDK 不在列表里，就需要先注册：

sudo update-alternatives --install /usr/bin/java java /opt/jdk-17/bin/java 1700 \ --slave /usr/bin/javac javac /opt/jdk-17/bin/javac \ --slave /usr/bin/jar jar /opt/jdk-17/bin/jar

注意，这里我把javac和jar用--slave挂在了同一个组下，这样以后切换java时，编译工具和打包工具会一起变。只注册java不注册javac的话，很容易出现编译版本和运行版本不一致，排查起来相当折磨人。

还有一个细节：注册时如果指定的 slave 路径不存在，命令会报错。所以手工解压的 JDK，注册之前先确认一下/opt/jdk-17/bin/javac、/opt/jdk-17/bin/jar这些文件是不是真的在，缺哪个就少列哪个 slave，别贪多。

3.2 案例二：编辑器默认值切换

很多发行版的桌面环境中，editor组是几个编辑器公共入口。装了一堆编辑器后，想设定默认的文本编辑器，就可以用：

sudo update-alternatives --config editor

同理，vi组也是一个经典例子。它底下通常挂着view、vimdiff、rvi、rvim、ex等一串从链接。你可能会好奇为什么有这么多条，其实这些命令都是同一族编辑器，只是入口不同。把它们做成 slave 链接，就是为了保证“你切的是整套 vi 生态，而不是只切了其中一个命令”。

这里我建议查看一下vi组里具体有哪些候选，很多人会惊讶地发现系统里默认就有好几套不同的 vim 变体和传统 vi，平时根本没注意到它们还能切换。

3.3 案例三：多个编译器版本共存

编译器场景和 Java 几乎一样。假设系统里同时装着 gcc 12 和 gcc 13，你可以：

sudo update-alternatives --list gcc sudo update-alternatives --config gcc

不过要提醒一下，gcc和cc是两组独立的 alternatives。如果你编译某些项目时依赖的是cc，光切gcc组可能没用，还得单独看cc组。这种“同名但不同组”的坑我在实际项目里踩过不止一次，切换完记得用cc -v或gcc -v分别确认。

如果是自动化部署，非交互式指定更合适：

sudo update-alternatives --set gcc /usr/bin/gcc-13

3.4 用脚本读取切换结果

我自己的习惯是切完之后做一个断言，避免人眼漏看。用--query配合文本处理就能实现：

sudo update-alternatives --query java | grep '^Value:' | awk '{print $2}'

如果这个输出不是你期望的路径，说明切换没有生效，或者系统的 manual 状态把优先级压住了。在自动化流程里，我会把这个值拿去和期望值比对，不一致就告警。做巡检脚本时，这个方法比单纯看--display的输出稳定得多。

4. 踩坑报告：这些情况会让 alternatives 失灵或误切

工具本身不难，难的是它和你在 shell 里随手建的那些符号链接混在一起时，场面会变得很混乱。下面这几种情况我基本都遇到过，列出来帮大家提前避雷。

4.1 手动修改 /usr/bin 下的公共链接，导致切换不生效

我最初犯的一个错就是图省事，直接用ln -sfn /opt/jdk-17/bin/java /usr/bin/java把/usr/bin/java强行指到实际路径。命令倒是能跑，但 alternatives 并不知道这件事。你执行update-alternatives --config java时，它改的是/etc/alternatives/java这条中间链接，而/usr/bin/java既然已经被你改成了直连实际路径，根本不会去读/etc/alternatives/java，所以怎么切都没反应。

正确做法是先把公共链接恢复成指向/etc/alternatives/java：

sudo ln -sf /etc/alternatives/java /usr/bin/java

然后再通过update-alternatives --config java切换。记住：/usr/bin下的入口由系统维护，我们不应该直接去改它的目标，所有变更都走 alternatives 本身。

4.2 被 manual 模式“锁死”的高优先级候选

这是个很容易误判的场景：你明明--install了一个优先级更高的新版本，结果java -version纹丝不动。第一反应往往是“是不是没注册成功”，但--display一看，候选已经在列，而且优先级确实更高。

这时多半是因为该组处于 manual 模式。之前某次操作用了--config或--set，系统就记住了你的手动选择，不管后来优先级多高，它都优先尊重你的选择。解决办法很简单，如果你确实想让系统重新按优先级自动决策：

sudo update-alternatives --auto java

之后优先级最高的候选就会生效。反过来，如果你希望锁定某个稳定版本不变，manual 模式反而是个优点，别视它为 bug。

4.3 移除候选后，系统“自作主张”选了另一个

有人注册了一串候选，后来觉得某个版本的路径不对，想删掉其中一个，执行：

sudo update-alternatives --remove java /opt/old-jdk/bin/java

结果发现当前生效的默认版本被切换到了另一个候选。这其实不是 bug，而是设计如此：你删掉了当前生效的候选，系统当然要从剩余的候选中重新挑一个最优的。更需要注意的是，如果一个组只剩一个候选，移除这个候选后整个组都会被清理掉，相关的公共链接也会被一并删除。所以执行--remove之前，最好先想清楚“删掉之后默认会变成谁”，别等到命令跑完才回过神来。

4.4 slave 链接没注册全，出现版本撕裂

只注册java不注册javac的情况，我前面提到过。扩展一下：即使注册了 slave，也要注意每个候选都要在同一套--install里声明。alternatives 没有“事后补挂 slave”的命令，你如果发现注册时漏了某个从链接，只能先--remove掉这个候选，再用完整的--install重新注册一次。

有人会想直接改/var/lib/dpkg/alternatives/下的状态文件来补，我强烈不建议。这个文件格式虽然看起来不复杂，但内容一旦写得不对，轻则update-alternatives报解析错误，重则导致包管理器升级时把整个组的状态冲掉。想改配置，永远走命令工具。

5. 进阶玩法：手工建立一个自己的 alternatives 组

前面讲的都是系统里已经存在的组，但 alternatives 的能力远不止于此。它完全可以为任何一组相互替代的程序做“版本切换面板”，尤其是公司内部工具、编译产物、脚本集合这类不通过系统包管理器安装的东西。

5.1 为什么值得自己建组

假设你有一把内部工具，不同项目需要不同大版本，比如/opt/mytool-1.0/bin/mytool和/opt/mytool-2.0/bin/mytool。正常做法可能是写一堆脚本去改 PATH，但脚本维护起来很分散，而且不同人机器的状态很难保持一致。把工具注册成 alternatives 组之后，一切切换都收敛到同一套命令上：update-alternatives --config mytool，既直观又统一，还留了历史状态可查。

5.2 一条命令注册主链接和从链接

注册一个自定义组，思路和注册 JDK 完全一样：

sudo update-alternatives --install /usr/bin/mytool mytool /opt/mytool-2.0/bin/mytool 200 \ --slave /usr/bin/mytool-dump mytool-dump /opt/mytool-2.0/bin/mytool-dump \ --slave /usr/bin/mytool-restore mytool-restore /opt/mytool-2.0/bin/mytool-restore

这里组名是mytool，公共链接是/usr/bin/mytool，两个从链接分别是mytool-dump和mytool-restore。这样切换mytool版本时，配套命令也会一起联动。不过要注意一点：如果你在同一个组里注册多个候选，每个候选对应的 slave 路径都必须真实存在，否则注册失败；而如果你已经给mytool组挂过mytool-dump这个从链接，再给别的组挂同一个/usr/bin/mytool-dump，就会出现链接入口冲突，系统只会允许其中一个处理它。

5.3 结合优先级设计“稳定优先”和“测试优先”

自建组时优先级怎么给，其实是一种策略设计。如果你希望系统默认用稳定版，就把稳定版的优先级设高一些，组保持 auto 模式，日常无需干预。如果某个阶段想全体切换到测试版做验证，可以执行一次--set或--config把它手动改过去，因为这时组变成 manual，之后即使稳定版优先级更高，系统也不会上来抢。

这个“自动按优先级 + 手动锁定覆盖”的组合，我用下来觉得非常适合工具链灰度发布。稳定版永远躺在高优先级位置，测试版只在需要时被手动选中，不会被升级动作悄悄改变。

5.4 理解包管理器为什么会自动触发它

如果你用过 DEB 体系的发行版，会发现很多软件包安装完，update-alternatives --display xxxx里就已经有了对应候选。这靠的是软件包的维护脚本，在安装阶段自动调用--install，卸载阶段自动调用--remove。理解了这个机制，你就能明白为什么“谁提供的命令谁来登记、谁来清理”这个分工如此清晰，也能解释为什么你在/usr/bin下看到的命令，很多都不是真实文件，而是一层层符号链接拼出来的整合结果。自建组时也建议把--install和--remove的逻辑写进你自己的安装脚本里，这样卸载的时候不会留下孤儿候选，长期维护会轻松很多。

最后再分享一个小习惯：每次操作完一个组，我都会顺手跑一下update-alternatives --display <组名>，确认link currently points to那一行是不是我预期的路径。这个动作看起来多余，但能直接避免大量“咦怎么没生效”的后续排查；脚本化环境里，就用--query抓Value:字段做断言。玩转 alternatives 不难，难的是始终保持“让工具管链接，而不是自己动手造链接”的边界感。