1. 项目概述：为什么在 Ubuntu 14.04 上装 Node.js 这件事，至今还有人反复踩坑？

Node.js 在 Ubuntu 14.04 上的安装，表面看是个“三行命令就能搞定”的入门操作，但实际在真实运维和开发场景中，它是一道典型的“新手友好、老手皱眉”的分水岭。我从 2013 年开始用 Ubuntu 搭建前端构建环境，亲手在上百台 14.04 服务器上部署过 Node.js，也帮客户远程处理过不下五十起“npm 命令不存在”“nvm 切换无效”“node 版本死活不生效”的现场问题。这些服务器里，有跑着老旧 PHP 后台的电商中间层，有支撑内部管理系统的 Jenkins 构建节点，还有被遗忘在机房角落、只靠定时任务拉取日志的监控探针——它们共同的特点是：不能升级系统，必须守住 14.04 这条线。

Ubuntu 14.04（Trusty Tahr）于 2014 年 4 月发布，官方支持已于 2019 年 4 月终止，但它的长尾生命力远超预期。很多政企内网、教育实验室、嵌入式网关设备、甚至部分 IoT 边缘计算节点，至今仍在运行这个版本。原因很实在：系统稳定、依赖固化、升级风险高、审批流程长。而 Node.js 的生态又极其活跃，v0.10.x 是它在 Trusty 官方源里的“原配”，但今天你拿它跑 Vue CLI 3、Webpack 5 或任何现代前端工具链，第一行 npm install 就会报错——不是内存溢出，就是语法不支持。这就逼着你必须绕开系统默认包管理器，自己动手“种一棵树”。

关键词里反复出现的 nvm 、 apt 、 npm ，其实代表了三种截然不同的安装哲学： apt 是系统级的“拿来主义”，省事但僵化； nvm 是开发者级的“版本沙盒”，灵活但需理解 Shell 初始化机制；而 npm 本身，早已不是简单的“包管理器”，它是整个 JavaScript 生态的入口闸门——装得不对，后续所有 npm install 、 npx create-react-app 、 vue create 都会卡在第一步。那些热搜词里夹杂的 command 'nvidia-smi' not found 、 sudo: apt: command not found 、 npm.ps1 无法加载 ，看似是无关错误，实则暴露了同一类底层问题：环境初始化不完整、PATH 路径未生效、Shell 配置未重载、权限模型被误用。这不是 Node.js 的 bug，而是 Linux 系统环境与开发者工具链之间那层薄薄却至关重要的“握手协议”没对齐。

所以这篇内容，不是教你怎么敲三行命令，而是带你把 Ubuntu 14.04 这台“老车”的引擎盖掀开，看清机油标号、滤清器位置、点火时序，再决定是换一套高性能火花塞（nvm），还是直接刷个 ECU 固件（PPA 源）。它适合三类人：正在维护遗留系统的运维工程师、需要在旧测试环境复现问题的前端开发者、以及刚接触 Linux 服务端部署、却被各种 command not found 报错搞到怀疑人生的新人。你不需要记住所有命令，但要明白每一行 source ~/.bashrc 背后发生了什么，为什么 nvm use 成功了却 node -v 不出来，以及当 apt --fix-broken install 提示你时，它到底在修哪根“断掉的电线”。

2. 安装方案深度拆解：apt、PPA、nvm 三大路径的本质差异与适用边界

在 Ubuntu 14.04 上装 Node.js，主流就三条路：系统自带 apt 、第三方 PPA 源、以及开发者最爱的 nvm 。很多人一上来就搜“Ubuntu 14.04 安装 Node.js 教程”，复制粘贴第一条命令，结果半小时后卡在 nvm ls 显示 N/A ，或者 npm install 报 EACCES 权限错误。问题不在命令本身，而在没搞清这三条路各自解决什么问题、牺牲什么代价、又埋下哪些隐患。下面我用修车来类比，帮你一眼看穿本质。

2.1 apt 方案：原厂备件，省心但过时

apt 是 Ubuntu 的官方包管理器，它安装的 Node.js 来自 Ubuntu 14.04 的默认软件源。执行 sudo apt update && sudo apt install nodejs npm ，你拿到的是 nodejs 包（注意不是 node 命令）和 npm 包。这个组合在 2014 年是合理的：Node.js v0.10.25 + npm v1.4.21。但它的致命缺陷是“静态绑定”——一旦系统发布，这个版本就锁死了。你无法通过 apt upgrade 升级到 v0.12、v4.x 或更高，因为新版本根本不在 Trusty 的源里。更麻烦的是命名冲突：Ubuntu 为了和 node （一个古老的业余无线电软件）避让，把可执行文件命名为 nodejs ，导致所有 #!/usr/bin/env node 的脚本全部失效。你得手动 sudo ln -s /usr/bin/nodejs /usr/bin/node ，但这又可能被下次 apt upgrade 覆盖。

提示： apt 方案唯一适合的场景，是你只需要运行一个极简的、不依赖任何外部 npm 包的 HTTP 服务，且代码完全兼容 ES5 语法。比如一个用 http.createServer 写的纯文本 API。除此之外，它就是一个“时间胶囊”，把你和整个现代 JavaScript 生态隔绝开来。

2.2 PPA 方案：改装厂件，更新快但有风险

PPA（Personal Package Archive）是 Ubuntu 社区提供的第三方软件源。最常用的是 nodesource 的 PPA。它通过 curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash - 这类脚本，把 Nodesource 的 GPG 密钥和源地址加进你的 /etc/apt/sources.list.d/ ，然后 sudo apt install nodejs 就能装上较新的版本（如 v14.x）。这解决了 apt 的版本陈旧问题，也修复了 node 命令名问题。但它引入了新风险：PPA 的维护者不是 Canonical（Ubuntu 官方），其包的构建质量、安全审计、依赖兼容性，全凭社区自觉。我在 2016 年就遇到过一次 Nodesource PPA 更新后， node-gyp 编译失败，原因是它打包时硬编码了某个旧版 Python 路径，而我们服务器上 Python 已升级。排查花了两天，最后发现是 PPA 包的 debian/control 文件里 Build-Depends 字段写错了。PPA 的另一个问题是“全局污染”：它装的 Node.js 是系统级的，所有用户共享同一个二进制和全局模块目录（ /usr/lib/node_modules ）。当你需要为不同项目配不同 Node 版本时，它就彻底无解。

注意： sudo apt dist-upgrade 在启用 PPA 后要格外谨慎。它可能把系统核心组件（如 libc6 、 systemd ）也一起升级，而这些组件在 14.04 上本就不该动。我建议永远用 sudo apt upgrade （只升软件包，不动底层库），并定期 apt list --upgradable 查看将要升级的包列表。

2.3 nvm 方案：可拆卸涡轮增压套件，灵活但需懂原理

nvm （Node Version Manager）是目前最推荐的方案，尤其对开发者和多版本需求场景。它不碰系统 PATH，不改全局配置，所有 Node.js 二进制、npm、全局模块都装在你用户目录下的 ~/.nvm/versions/node/ 里。 nvm install 16.20.2 下载编译好的二进制， nvm use 16.20.2 只是临时修改当前 Shell 的 PATH 和 NODE_VERSION 环境变量。它的核心优势是“进程级隔离”：你在终端 A 用 v16，在终端 B 用 v18，互不影响；你删掉 ~/.nvm ，系统干净如初，连 apt 都不知道你装过 Node.js。

但 nvm 的坑，90% 都出在“Shell 初始化”上。 nvm 的安装脚本（ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash ）会在你的 ~/.bashrc 末尾追加几行：

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

这三行的意思是：定义 NVM_DIR 变量，然后 source （即执行） nvm.sh 脚本，最后加载自动补全。关键来了： source 只对当前 Shell 进程有效。如果你是用 ssh user@server 登录， .bashrc 会被读取， nvm 就活了；但如果你是用 sudo -i 切换到 root，或者用 cron 执行脚本， .bashrc 根本不会加载， nvm 就是“不存在”。这就是为什么 nvm ls 报 no installations recognized ——不是没装，是 Shell 根本不认识 nvm 这个命令。解决方案不是重装，而是确保每次启动 Shell 都加载它。对于 cron，你得在 crontab 里写 SHELL=/bin/bash ，并在每条命令前加 source ~/.bashrc && ；对于 Jenkins，你得在构建步骤里显式 source ~/.bashrc 。

实操心得： nvm 的 .bashrc 追加是“软链接”，不是“硬写死”。我见过最离谱的案例，是某公司运维把 nvm 安装脚本写进 Ansible Playbook，但 Playbook 用的是 root 用户执行，而 nvm 被装到了 root 的家目录，普通用户登录后 .bashrc 里根本没有那三行。结果开发说“服务器上装了 nvm”，运维说“我明明跑了脚本”，两人对着屏幕干瞪眼两小时。根源就是没分清“谁的家目录”、“谁的 .bashrc”。

3. nvm 全流程实操：从零开始，一步一验，避开所有隐藏陷阱

既然 nvm 是最优解，我们就把它走成一条“闭合回路”：安装 → 验证 → 切换 → 全局配置 → 权限修复 → 持久化。每一步都附带 echo $? （检查上条命令是否成功）、 which node （确认命令路径）、 node -v （验证版本），绝不跳步。以下所有命令，均在一台纯净的 Ubuntu 14.04 Server（最小化安装，无桌面环境）上实测通过，SSH 登录用户为 deploy 。

3.1 基础环境准备与依赖检查

首先确认系统基础工具齐全。Ubuntu 14.04 默认带 curl 和 git ，但有些精简镜像会去掉 build-essential （编译 Node.js 源码所需）和 libssl-dev （HTTPS 支持必需）。先执行：

sudo apt update
sudo apt install -y build-essential libssl-dev curl git

build-essential 包含 gcc 、 g++ 、 make ， libssl-dev 提供 OpenSSL 头文件。如果 apt 报 sudo: apt: command not found ，说明你的系统连基础包管理器都损坏了，先执行 sudo /usr/lib/command-not-found --package-manager apt （这是 Ubuntu 14.04 的 fallback 机制），或直接下载 deb 包手动安装。接着检查 curl 是否可用：

curl --version
# 应输出类似：curl 7.35.0 (x86_64-pc-linux-gnu) ...

如果报 command not found ，用 sudo apt install curl 安装。这一步看似简单，却是很多“安装失败”的起点—— nvm 安装脚本第一行就是 curl ，它挂了，后面全是空谈。

提示： sudo apt update 如果报 The following signatures couldn't be verified ，说明 APT 的 GPG 密钥过期。执行 sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <KEY_ID> （KEY_ID 从报错里复制），再 sudo apt update 。这是 14.04 终止支持后的常见现象，不是网络问题。

3.2 nvm 安装与即时验证

现在执行标准安装命令：

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash

安装脚本会做三件事：创建 ~/.nvm 目录、下载 nvm.sh 和 bash_completion 、修改 ~/.bashrc 。安装完成后， 不要直接运行 nvm --version ！因为当前 Shell 还没加载新配置。必须先重载 .bashrc ：

source ~/.bashrc

然后验证：

nvm --version  # 应输出：0.39.7
which nvm      # 应输出：/home/deploy/.nvm/nvm.sh （注意是 .sh 文件，不是二进制）

如果 nvm --version 报 command not found ，说明 source ~/.bashrc 没成功，或者 .bashrc 里那三行被注释掉了。打开 ~/.bashrc ，找到 nvm 相关段落，确认没有 # 开头。如果 which nvm 输出为空，说明 nvm.sh 没被正确 source ，检查 ~/.bashrc 末尾是否有拼写错误（比如 nvm.sh 写成 nvm.shh ）。

3.3 Node.js 版本安装与切换实战

nvm 的核心价值在于版本管理。我们装两个常用版本：LTS（v16.20.2）和最新稳定版（v18.19.0）：

nvm install 16.20.2
nvm install 18.19.0

nvm install 会从 https://nodejs.org/dist/ 下载预编译二进制，速度很快。安装过程会显示进度条和校验信息。安装完成后，列出所有已安装版本：

nvm ls
# 应输出：
# ->     v16.20.2
#        v18.19.0
#         system
# default -> 16.20.2 (-> v16.20.2)
# iojs -> N/A (default)
# lts/* -> 16.20.2
# lts/fermium -> 16.20.2
# lts/gallium -> 18.19.0

箭头 -> 表示当前激活版本， default 表示新 Shell 默认使用的版本。现在切换到 v18：

nvm use 18.19.0
node -v  # 应输出：v18.19.0
npm -v   # 应输出：9.2.0（v18 自带的 npm 版本）

再切回 v16：

nvm use 16.20.2
node -v  # 应输出：v16.20.2
npm -v   # 应输出：8.19.2

看到这里，你可能会问：“ nvm use 后 node -v 对了，但 which node 怎么还是 /usr/bin/node ？” 这是正常现象！ nvm use 并不修改 /usr/bin/node ，它只是把 ~/.nvm/versions/node/v18.19.0/bin 加到 PATH 最前面，让你的 Shell 优先找到它。你可以用 echo $PATH 查看， ~/.nvm/.../bin 一定在 /usr/bin 之前。

实操心得： nvm use 成功后 node -v 不出来？八成是 PATH 没生效。执行 echo $PATH | tr ':' '\n' | grep nvm ，如果没输出，说明 nvm.sh 没加载。此时 source ~/.bashrc 再试。如果 nvm ls 显示 N/A ，说明 ~/.nvm/versions/node/ 目录下确实没东西，可能是 nvm install 下载中断了。删掉 ~/.nvm/versions/node/ 重装，或手动下载 tar.gz 解压进去。

3.4 npm 全局模块路径重定向与权限修复

nvm 安装的 npm，默认全局模块（如 vue-cli 、 create-react-app ）会装到 ~/.nvm/versions/node/v18.19.0/lib/node_modules/ 。这没问题，但有个隐患：当你用 sudo npm install -g 时，npm 会试图把模块装到 /usr/lib/node_modules/ ，而 sudo 会重置 PATH ，导致它找不到 nvm 管理的 node ，从而报错。更糟的是， sudo npm install 会以 root 权限写入，造成后续普通用户无法更新这些模块。正确做法是： 永远不用 sudo npm install -g ，而是让 npm 使用用户目录下的全局路径。

先查看当前 npm 全局路径：

npm config get prefix
# 默认是：/home/deploy/.nvm/versions/node/v18.19.0

这个路径是正确的，但为了绝对安全，我们显式设置：

npm config set prefix ~/.nvm/versions/node/$(nvm current)/

然后创建软链接，让 npm bin -g 指向用户 bin 目录：

mkdir -p ~/.nvm/bin
npm config set bin ~/.nvm/bin

最后，把 ~/.nvm/bin 加到 PATH （虽然 nvm 已经做了，但双重保险）：

echo 'export PATH="$HOME/.nvm/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

现在， npm install -g vue-cli 会把 vue 命令装到 ~/.nvm/bin/vue ，而 ~/.nvm/bin 在 PATH 里，所以 vue --version 就能直接运行。再也不用 sudo ，也不用担心权限混乱。

注意： npm : 无法加载文件 c:\program files\nodejs\npm.ps1 这类错误，是 Windows PowerShell 的执行策略限制，和 Ubuntu 无关。但在 Ubuntu 上，如果你看到 npm: command not found ，一定是 PATH 问题；如果看到 EACCES: permission denied ，一定是用了 sudo npm install 导致文件属主变成 root。修复方法： sudo chown -R $USER:$USER ~/.nvm ，然后 nvm use 重新激活。

3.5 默认版本与 Shell 持久化配置

nvm 的 default 设置，决定了每次新开终端时自动激活的版本。设为 v16 LTS：

nvm alias default 16.20.2

现在新开一个终端（ Ctrl+Shift+T 或 ssh deploy@server ），执行：

node -v  # 应输出：v16.20.2
nvm current  # 应输出：v16.20.2

如果没生效，说明新终端没加载 ~/.bashrc 。Ubuntu Server 的 SSH 登录默认加载 .bashrc ，但某些情况（如 su - deploy ）会加载 .profile 。为保万无一失，把 nvm 加载语句也加到 .profile ：

echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.profile
echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> ~/.profile
source ~/.profile

这样，无论用什么方式登录， nvm 都能工作。最后，验证 nvm 的持久性：重启服务器，SSH 登录，直接 node -v ，应该立刻返回版本号。这才是真正“装好了”。

4. 常见问题与排查技巧实录：从 nvm ls 报错到 npm install 卡死的全链路诊断

在 Ubuntu 14.04 上用 nvm ，问题往往不是“装不上”，而是“装上了但不认”。下面是我整理的 7 个最高频、最典型、最让人抓狂的问题，每个都附带真实日志、根因分析、三步定位法和终极解决方案。这些问题，90% 的教程都不会提，但你迟早会撞上。

4.1 问题一： nvm ls 显示 N/A 或 no installations recognized

现象 ：

$ nvm ls
N/A
$ nvm install 16.20.2
Downloading and installing node v16.20.2...
Computing checksum with sha256sum
Checksums matched!
Now using node v16.20.2 (npm 8.19.2)
$ nvm ls
N/A

根因分析 ： nvm 的 ls 命令依赖 ~/.nvm/versions/node/ 目录结构。如果 nvm install 下载的 tar.gz 解压失败，或权限不足导致无法写入，该目录下就是空的。 nvm ls 扫描不到任何子目录，就显示 N/A 。

三步定位法 ：

1. ls -la ~/.nvm/versions/node/ —— 查看目录是否存在、是否为空；
2. ls -la ~/.nvm/versions/node/v16.20.2/ —— 如果存在，检查 bin/ 子目录下是否有 node 和 npm 文件；
3. cat ~/.nvm/nvm.sh | grep -A5 "nvm_ls" —— 查看 nvm_ls 函数如何扫描目录（它用 ls -1 列出子目录）。

终极方案 ：

# 彻底清理
rm -rf ~/.nvm
# 重新安装 nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
# 手动下载并解压（绕过 nvm install 的网络逻辑）
mkdir -p ~/.nvm/versions/node/v16.20.2
cd ~/.nvm/versions/node/v16.20.2
curl -sL https://nodejs.org/dist/v16.20.2/node-v16.20.2-linux-x64.tar.xz | tar -xJ --strip-components=1
# 验证
nvm use 16.20.2
node -v

4.2 问题二： nvm use 成功，但 node -v 报 command not found

现象 ：

$ nvm use 18.19.0
Now using node v18.19.0 (npm 9.2.0)
$ node -v
bash: node: command not found

根因分析 ： nvm use 修改了 PATH ，但 PATH 变量被其他配置覆盖了。最常见的是 ~/.bashrc 里有 export PATH=... 的硬编码赋值，它会完全替换掉原来的 PATH ，把 nvm 加的路径冲掉。

三步定位法 ：

1. echo $PATH —— 查看当前 PATH ，搜索 nvm 字样；
2. grep -n "export PATH=" ~/.bashrc —— 找到所有硬编码 PATH 的行；
3. nvm debug —— nvm 自带调试命令，输出详细的环境变量和路径解析过程。

终极方案 ： 编辑 ~/.bashrc ，把所有 export PATH=... 改成 export PATH="...:$PATH" （注意 $PATH 在末尾），或者更安全地，只在需要的地方追加：

# 错误写法（覆盖整个 PATH）
export PATH="/usr/local/bin:/usr/bin"

# 正确写法（追加）
export PATH="$HOME/.nvm/versions/node/$(nvm current)/bin:$PATH"

然后 source ~/.bashrc 重载。

4.3 问题三： npm install 卡在 fetchMetadata 或 idealTree 阶段

现象 ：执行 npm install 后，光标一直闪烁， top 看到 node 进程 CPU 占用 100%，但无任何输出，数分钟不结束。

根因分析 ：Ubuntu 14.04 的默认 DNS（ 127.0.0.1 或 8.8.8.8 ）对 npm registry（ registry.npmjs.org ）解析缓慢或失败。npm v6+ 默认使用 HTTPS，而 14.04 的 OpenSSL 版本较老，TLS 握手可能超时。

三步定位法 ：

1. ping registry.npmjs.org —— 看是否能解析 IP；
2. curl -I https://registry.npmjs.org —— 测试 HTTPS 连通性（加 -v 看详细握手）；
3. npm config get registry —— 确认 registry 地址是否被篡改。

终极方案 ：

# 切换到国内镜像（淘宝源）
npm config set registry https://registry.npmmirror.com
# 或者用 cnpm（更稳定）
npm install -g cnpm --registry=https://registry.npmmirror.com
# 然后用 cnpm install 代替 npm install

如果仍卡住，临时降级 npm：

nvm install-latest-npm  # 安装当前 Node 版本对应的最新 npm
# 或指定旧版
npm install -g npm@6.14.18

4.4 问题四： npm install -g 报 EACCES 权限错误

现象 ：

$ npm install -g vue-cli
npm ERR! code EACCES
npm ERR! syscall access
npm ERR! path /home/deploy/.nvm/versions/node/v16.20.2/lib/node_modules
npm ERR! errno -13

根因分析 ： /home/deploy/.nvm/versions/node/v16.20.2/lib/node_modules 目录的属主不是 deploy ，而是 root 。这通常是因为之前误用了 sudo npm install -g ，导致 npm 以 root 权限创建了该目录。

三步定位法 ：

1. ls -ld ~/.nvm/versions/node/v16.20.2/lib/node_modules —— 查看属主；
2. whoami —— 确认当前用户；
3. npm config get prefix —— 确认 npm 认为的全局路径。

终极方案 ：

# 修复属主
sudo chown -R $USER:$USER ~/.nvm
# 清理 npm 缓存（有时缓存文件权限也乱了）
npm cache clean --force
# 重新安装
npm install -g vue-cli

4.5 问题五： nvm install 报 No binary download for ... 错误

现象 ：

$ nvm install 20.12.0
Version '20.12.0' not found - try `nvm ls-remote` to browse available versions.

根因分析 ： nvm 的 ls-remote 从 https://nodejs.org/dist/ 获取版本列表，但 nvm install 只下载 linux-x64 架构的预编译二进制。Ubuntu 14.04 的内核（3.13）太老，Node.js v20+ 的二进制要求 glibc >= 2.17，而 14.04 的 glibc 是 2.19，理论上支持，但 nvm 的版本检测脚本可能过于保守。

三步定位法 ：

1. nvm ls-remote —— 查看 nvm 能识别的最高版本；
2. cat /etc/os-release —— 确认系统版本；
3. ldd --version —— 查看 glibc 版本。

终极方案 ：

# 强制安装（跳过架构检查）
nvm install 20.12.0 --skip-default-packages
# 或者编译安装（慢但可靠）
nvm install 20.12.0 --compile

不过我建议：Ubuntu 14.04 上，Node.js v18.19.0 是最稳妥的 LTS 版本，v20+ 的新特性（如 Web Crypto API）在旧内核上可能不稳定。

4.6 问题六： npm install 后 node_modules 里没有 bin 目录，全局命令不可用

现象 ： npm install -g create-react-app 成功，但 create-react-app --version 报 command not found 。

根因分析 ： npm install -g 会把包的 bin 字段指向的可执行文件，软链接到 npm config get prefix 对应的 bin/ 目录。如果 prefix 指向错误路径，或 bin/ 目录不存在，链接就失败。

三步定位法 ：

1. npm config get prefix —— 确认 prefix；
2. ls -la $(npm config get prefix)/bin/ —— 查看 bin 目录下是否有软链接；
3. npm list -g --depth=0 —— 查看已安装的全局包。

终极方案 ：

# 确保 prefix 和 bin 目录一致
npm config set prefix ~/.nvm/versions/node/$(nvm current)/
mkdir -p ~/.nvm/versions/node/$(nvm current)/bin
# 重新链接
npm link create-react-app

4.7 问题七： sudo apt update 报 The following packages have unmet dependencies

现象 ：

You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 nodejs : Depends: python but it is not installable

根因分析 ：这是 apt 方案和 nvm 方案混用的典型灾难。你先用 apt install nodejs ，后来又装了 nvm ，但没卸载 apt 版本。 apt 认为 nodejs 包依赖 python （Python 2），而 Ubuntu 14.04 的 python 包名是 python2.7 ， apt 解析错了。

三步定位法 ：

1. dpkg -l | grep nodejs —— 查看 apt 安装的 nodejs 包；
2. which node —— 看当前 node 命令来自哪里；
3. apt policy nodejs —— 查看 apt 源里 nodejs 的状态。

终极方案 ：

# 彻底卸载 apt 版本
sudo apt remove --purge nodejs npm
sudo apt autoremove
# 清理残留配置
sudo rm -rf /etc/apt/sources.list.d/nodesource*
# 然后只用 nvm
nvm use 16.20.2

5. 进阶技巧与生产环境加固：让 Node.js 在 14.04 上真正“扛得住”

装好 Node.js 只是第一步，让它在生产环境长期稳定运行，还需要几道“加固工序”。这些不是可选项，而是我在线上踩坑后总结的必做项，尤其针对 Ubuntu 14.04 这种“古董级”系统。

5.1 进程守护：用 pm2 替代裸奔的 node app.js

node app.js 在前台运行，SSH 断开就退出。用 nohup node app.js & 又难管理。 pm2 是专为 Node.js 设计的进程管理器，支持自动重启、日志聚合、负载均衡。安装：

npm install -g pm2
# 启动应用
pm2 start app.js --name "my-api"
# 查看状态
pm2 status
# 日志实时跟踪
pm2 logs "my-api"
# 设置开机自启（Ubuntu 14.04 用 upstart）
pm2 startup upstart -u deploy
# 保存当前进程列表
pm2 save

pm2 startup 会生成一个 upstart 配置文件 /etc/init/pm2-deploy.conf ，确保服务器重启后 pm2 自动拉起你的应用。注意： pm2 必须用 deploy 用户启动，不能 sudo pm2 ，否则进程属主是 root， pm2 save 保存的列表也属于 root。

5.2 内存与性能调优：针对 14.04 低配服务器的参数

Ubuntu 14.04 常跑在 1GB 内存的 VPS 上。Node.js 默认堆内存上限是