Linux 服务器怎么通过 Nodesource 或 nvm 升级 Node.js

图 0：Linux 服务器升级 Node.js 的两种核心路径与应用定位

在 Linux 服务器上升级 Node.js，核心路径主要分为两类：一是通过 NodeSource 提供的官方包存储库，将系统级全局二进制文件平滑升级到指定的主版本；二是通过 nvm（Node Version Manager）在用户目录下按需拉取、安装并切换多套 Node.js 环境。如果你运维的服务器是以单一商业服务为主、由 systemd 统一托管的生产实例，优先采用 NodeSource；如果你是在一台主机上部署多个依赖不同 Node.js 版本的老旧项目，或当前登录账号没有 sudo 提权权限，nvm 则是更加稳妥高效的方案。

一、升级前的决策与选型

在敲下任何安装命令之前，先根据服务器当前的权限状况与运维模式做出明确选择。系统级包管理器（apt/dnf）直接覆盖 /usr/bin/node，对生产守护进程完全透明；而 nvm 依赖 Shell 环境变量的重定向，如果配置不当，可能导致后台服务在非交互式会话中找不到执行路径。

图 1：Linux 环境升级 Node.js 决策树

二、方案一：通过 NodeSource 升级系统级 Node.js

NodeSource 维护着针对 Debian、Ubuntu、RHEL、CentOS 等发行版的官方编译源。通过官方源升级，本质上是把系统的 APT 或 DNF 源指向更高版本（如 Node.js 20.x 或 22.x LTS），然后调用包管理器替换 /usr/bin/node 和 /usr/bin/npm。

图 2：NodeSource 系统级升级与服务恢复流程

1. 针对 Ubuntu / Debian 系统的操作步骤

NodeSource 自 2023 年下半年起弃用了旧有的 setup_XX.x 脚本一键执行方式，转而推荐使用符合现代 Debian 规范的独立 Keyring 签名源机制。以下以升级至 Node.js 20.x LTS 为例：

# 1. 检查当前版本与依赖包
node -v
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg

# 2. 清理可能存在的历史源定义文件，避免多源冲突
sudo rm -f /etc/apt/sources.list.d/nodesource.list

# 3. 导入 NodeSource 官方 GPG 密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

# 4. 写入目标版本源配置（NODE_MAJOR 可指定为 20、22 等稳定主版本）
NODE_MAJOR=20
echo "deb [signed-by=/etc/apt/keyrings/nodesource.gpg] https://deb.nodesource.com/node_$NODE_MAJOR.x nodistro main" | sudo tee /etc/apt/sources.list.d/nodesource.list

# 5. 更新软件索引并安装/升级 nodejs
sudo apt-get update
sudo apt-get install -y nodejs

升级完成后，检查版本以确认升级生效：

node -v
npm -v

2. 针对 RHEL / CentOS / Rocky Linux 系统的操作步骤

在基于 RPM 的发行版中，Enterprise Linux 8/9 内置了 nodejs 的 AppStream 模块，升级前需要先重置模块流，以免系统继续锁定旧版：

# 1. 如果系统启用了 AppStream 模块流，先将其重置（CentOS Stream / Rocky Linux 8/9）
sudo dnf module reset nodejs -y

# 2. 获取并执行 NodeSource RPM 安装脚本（以 Node.js 20.x 为例）
curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -

# 3. 执行安装或升级
sudo dnf install -y nodejs

# 4. 如果之前已安装旧版本且提示无需更新，使用 upgrade 显式更新
sudo dnf upgrade -y nodejs

三、方案二：通过 nvm 在用户空间平滑升级

nvm（Node Version Manager）是一个基于 Bash/Zsh 的版本管理脚本。它将各个版本的 Node.js 独立安装在当前用户的家目录 ~/.nvm/versions/node/ 下，并在需要时通过调整 PATH 环境变量来切换版本。这种方式完全不触碰系统的全局目录，对于无 sudo 权限、或需要多个 Node.js 版本共存的机器尤为适用。

图 3：nvm 多版本安装机制与环境变量定向

1. 升级 nvm 工具本身

在安装新版 Node.js 之前，建议先确保 nvm 本身是较新版本，否则可能无法正确解析最新的 LTS 版本代号。可以通过官方脚本拉取最新标签（目前常用 v0.39.7 及以上）：

# 检查当前 nvm 版本
nvm --version

# 如果版本过旧，拉取最新安装脚本重新载入
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

# 重新加载 shell 配置
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

2. 查询并安装目标 Node.js 版本

nvm 支持直接使用主版本号（如 20）或 --lts 参数自动匹配最新稳定版。通过 --reinstall-packages-from 参数，还能把老版本里安装过的全局工具（如 pm2、yarn、pnpm 等）同步复制到新版本：

# 列出所有可用的 LTS 长期维护版本
nvm ls-remote --lts

# 安装 Node.js 20 LTS，并自动迁移当前环境的全局 npm 包
nvm install 20 --reinstall-packages-from=current

3. 切换默认版本与验证

使用 nvm install 后，当前终端会自动切换到新版本，但为了保证下次登录服务器或重启后依然默认使用该版本，必须显式更新 default 别名：

# 确认当前使用的版本
nvm current

# 将默认 Node.js 别名指向 20
nvm alias default 20

# 验证全局路径
which node
node -v

四、升级后的验证与常见问题排查

1. 原生 C++ 模块（node-gyp）兼容性报错

跨大版本升级 Node.js（例如从 18.x 升级到 20.x）时，底层 V8 引擎的 ABI（Application Binary Interface）会发生变化。如果项目中使用了 bcrypt、sharp、node-canvas 等包含 C++ 扩展的第三方库，服务启动时可能报 ERR_DLOPEN_FAILED 或 NODE_MODULE_VERSION mismatch 错误。

解决办法：进入各个项目根目录，重新编译或重新安装依赖：

# 清理已编译的原生构建文件并重新编译
npm rebuild

# 或者在项目根目录重装
rm -rf node_modules
npm install

2. PM2 守护进程找不到新版本 Node

如果在升级前 PM2 已经作为守护进程常驻内存，升级系统 Node.js 或 nvm 后，PM2 的守护进程可能仍在引用旧版本的内存镜像。升级后需要执行更新指令：

# 保存当前运行的进程配置
pm2 save

# 重新加载 PM2 守护进程以应用新的 Node 运行环境
pm2 update

# 重载业务应用
pm2 reload all

3. 快速版本回退（Rollback）方案

如果升级后发现业务代码存在无法即时修复的兼容性缺陷，不同方案的回退成本差异极大：

• nvm 回退：极为轻松。只需执行 nvm use 18 && nvm alias default 18，几毫秒内即可回退到旧版本，不需要重新下载或解压。
• NodeSource 回退：需要先降低软件源版本，修改 /etc/apt/sources.list.d/nodesource.list 中的 NODE_MAJOR=18，然后执行 sudo apt-get update && sudo apt-get install --allow-downgrades -y nodejs=18.* 重新降级。

五、总结：核心方案对比与选择建议

对于大部分 Linux 运维场景，升级 Node.js 并不是越新越好，而是优先选择处于 Active LTS（长期支持）状态的偶数版本号（如 20.x、22.x）。生产环境应遵循“最小惊扰”原则，根据自身架构在 NodeSource 的系统一致性与 nvm 的灵活性之间取得平衡。

图 4：升级方式关键特性矩阵及最佳实践建议

综上所述，如果你的应用是由系统运维工程师通过自动化配置或 systemd 直接监管的生产服务，使用 NodeSource 能够保持系统包的一致性与简洁性；而如果你在维护着多个对 Node.js 运行时有差异化要求的服务，或者需要随时在不同版本之间进行快速对比和验证，nvm 则是更具备韧性的实用工具。