企业官网建设流程全解析

前两天帮一个同事排查 node 环境问题，他跟我说的第一句话是：“我把 node.js 卸载重装了，怎么还是不行？”我当时一愣，点开他的终端看了一眼，node -v显示的版本号确实还是旧的。后来他又折腾了半小时，问题依旧。我坐到他的电脑前检查了一圈，发现问题根本不在安装包，而在于卸载这一步压根就没卸干净——旧版本的残留文件还在，环境变量还在，npm 的全局包也散落在 AppData 里。这才是“卸载重装”无效的真相。

这篇文章就是把我那次排查过程总结成一套完整的操作规程，覆盖 Windows 和 CentOS 7.9 两条主线，从卸载前的准备、真正的清理流程，到版本选择、重新安装、初始化配置，再到重装后最常见的几个报错。无论你是前端、后端还是运维，只要你的电脑上装过 Node.js，迟早用得上这套方法。

1. 为什么卸载重装总是做不干净：先找到残留文件去了哪里

很多人对“卸载软件”的理解还停留在控制面板点一下“卸载”，再重新下载安装包点“下一步”就算完事。但 Node.js 不是一个单文件软件，它在安装时会同时往好几个互不相干的位置写入文件，任何一个位置没清干净，都可能让你“重装了等于没重装”。

1.1 Windows 下 Node.js 安装时的五个落点

以 Windows 为例，Node.js 至少会碰这些地方：

• 主安装目录：默认在C:\Program Files\nodejs，安装向导选路径时改过的话就在你指定的目录。
• npm 全局包目录：默认在C:\Users\你的用户名\AppData\Roaming\npm，所有npm install -g装进去的工具都躺在这里。
• npm 缓存目录：默认在C:\Users\你的用户名\AppData\Local\npm-cache，旧版 npm 可能写在AppData\Roaming\npm-cache。
• 环境变量 PATH：安装时会往系统和用户 PATH 里写入C:\Program Files\nodejs、%AppData%\npm等条目。
• 注册表：主要在HKEY_LOCAL_MACHINE\SOFTWARE\Node.js和HKEY_CURRENT_USER\SOFTWARE\Node.js。

问题就出在第三步。你通过“控制面板”或“设置”卸载，Windows 清理的是第一项主安装目录和注册表里登记过的条目，但 npm 全局包目录、npm 缓存、以及 PATH 里残留的旧路径，系统是默认“帮你保留”的。这些残留不会提示，也不会自动消失。

1.2 Linux 上的残留又藏在哪儿

在 Linux 上情况类似。以 CentOS 7.9 为例，如果你用yum install nodejs安装，包管理器的 remove 指令能清理大部分文件；但如果你当年用的是二进制包手动解压方式，那么安装者通常会把解压目录丢在/usr/local下面，同时在/usr/local/bin里做软链接。这种装法，yum remove nodejs压根不知道要删哪个目录。

比较隐蔽的还有几个：

• /usr/local/lib/node_modules，全局模块的落点。
• ~/.npm，npm 的缓存目录。
• ~/.npmrc，npm 配置文件。
• 还有nvm、n这类版本管理工具使用的独立目录，如果不走它们自带的卸载命令，直接删目录很容易留下“幽灵版本”。

1.3 残留文件到底会造成哪些实际问题

打个比方，卸载重装就像换一个新房客。你把旧房客赶走了，但他的行李还堆在客厅，新来的房客放行李时发现地方不够；更麻烦的是，旧房客在物业那里留的手机号还没改，快递依然会打给旧号码。

对应到 Node.js 上就是这三种典型症状：

• 新装的 Node 版本没生效，终端里node -v还是老版本号。
• 全局工具（比如pm2、nest、yarn）找不到了，或者报“无法加载”的错误。
• 安装某些依赖时出现诡异冲突，新版本和旧残留互相污染。

所以，如果你决定走“卸载重装”这条路，请把全程理解成两件事：第一，彻底清走旧房客的所有痕迹；第二，再请进新房客。下面先讲 Windows 的完整卸载。

2. Windows 卸载全流程：控制面板只是第一道工序

我先把结论摆在这里：Windows 上完整的卸载流程分四步——正式卸载、清理目录、清理环境变量、清理注册表。每一步都不要跳。

2.1 第一步：从“应用和功能”正式卸载

Win10 / Win11 用户建议走这条路径：打开设置 → 应用 → 应用和功能，在列表中找到 Node.js，点右侧的“卸载”。老版本系统也可以用控制面板 → 程序和功能。

这一步开始前，请先把所有开着 node.exe 的进程关掉。很多人在卸载时收到“文件正在使用”的弹窗，就是因为 VSCode、终端窗口或者其他软件里还挂着 Node 进程。最稳妥的办法是直接打开任务管理器，搜索node，全部结束进程，再执行卸载。

如果你追求彻底，也可以先用第三方卸载工具，比如 Geek Uninstaller。这类工具会在卸载后扫描残留文件和注册表项，帮你多清一层。但不要完全依赖它，后续两步还是得手动做一遍，当作复查。

2.2 第二步：手动清理四个残留目录

卸载完成后，按Win + R输入%AppData%回车，进入 Roaming 目录，找到npm文件夹直接删除。这个目录里存着你所有全局安装过的命令行工具，卸载 Node.js 时 Windows 不会动它，所以必须手动处理。

接着在同一个%AppData%路径下看看有没有npm-cache文件夹；再按Win + R输入%LocalAppData%，检查有没有npm-cache。两个位置都找到的话一并删除。另外别忘了一个最容易被忽略的位置：C:\Program Files\nodejs——如果它还在，直接整个删掉。

补充一个可选的命令行清理方法：打开一个管理员身份的终端，执行npm cache clean --force清理 npm 缓存。但如果你上面已经手动删了npm-cache目录，这一步可以跳过，因为缓存目录都没了。

2.3 第三步：清理 PATH 环境变量

这一步非常关键，也是大家最容易忽略的。右键“此电脑” → 属性 → 高级系统设置 → 环境变量，打开后分别检查用户变量和系统变量里的Path。

你需要把所有和 Node.js / npm 相关的条目删掉，常见的包括：

• C:\Program Files\nodejs\
• %AppData%\npm
• C:\Users\你的用户名\AppData\Roaming\npm
• 其他自定义过的 node 安装目录

双击 Path 条目，逐条选中这些路径删除即可。删的时候注意别误删其他软件加进去的路径，比如C:\Windows\System32这类系统路径一定保留。改完后所有窗口点“确定”关闭，重开一个终端才会生效。

2.4 第四步：注册表里搜 Node.js 残留（可选但建议做）

按Win + R输入regedit打开注册表编辑器，按Ctrl + F搜索Node.js。重点查看这两个位置：

• HKEY_CURRENT_USER\SOFTWARE\Node.js
• HKEY_LOCAL_MACHINE\SOFTWARE\Node.js

如果存在，右键删除。另外也可以用关键词nodejs再搜一遍，找到明确的 Node.js 安装相关项后删除。

这一步我要多提醒一句：操作注册表前，最好先在“文件 → 导出”里导出一份完整备份，防止误删后系统出问题。搜索时你会看到很多和 Node.js 无关但名称里带“node”的项，比如某些办公软件、即时通讯工具。不确定的项宁可不动，只要重点确认上面两个SOFTWARE\Node.js路径就好。

做完这四步，Windows 侧才算真正卸载干净。

3. CentOS 7.9 卸载 Node.js：按“当年怎么装的”决定“现在怎么卸”

和 Windows 不同，Linux 上卸载 Node.js 没有统一入口，正确做法是先搞清楚它当初是怎么被安装上来的。常见的安装方式有三种：包管理器安装、二进制包（或源码编译）安装、版本管理工具安装。下面分别说。

3.1 用 yum / dnf 安装的情况：包管理器一键卸载

CentOS 7.9 默认用 yum，CentOS 8 以后是 dnf。如果你当初是通过yum install nodejs装的，卸载就简单了：

yum remove -y nodejs

执行完后检查一下：

which node which npm

正常情况下会提示找不到命令。如果which node还能找到，说明除了 yum 之外，系统里还存在另一套 Node.js 安装，通常是手动解压或软链接造成的，继续往下看第二种情况。

3.2 二进制包或源码编译安装的情况：手动删除才是正解

这种装法最常见，因为 CentOS 7.9 自带源里的 Node.js 版本通常很老，很多人会选择下载官方二进制包解压到/usr/local下面。用这种装法，yum 完全管不到它，必须手动清理：

# 先找到 node/npm 的真实位置 which node which npm ls -l /usr/local/bin/node

二进制安装一般会创建软链接，比如/usr/local/bin/node -> /usr/local/node-v18.20.4-linux-x64/bin/node。你需要删除两类东西：

• 软链接本身：rm -f /usr/local/bin/node /usr/local/bin/npm /usr/local/bin/npx
• 真正的程序目录：rm -rf /usr/local/node-v18.20.4-linux-x64

再检查全局模块目录：

rm -rf /usr/local/lib/node_modules rm -rf ~/.npm

如果你不确定有没有其他关联目录，可以用这个命令列出所有可能在用的路径：

which -a node find /usr/local -name "node" -type l

找到一条删一条，直到node -v报错为止。

3.3 用 nvm / n 管理的情况：用工具自身的命令卸

很多人在 CentOS 上用的是 nvm 管理 Node 版本，这种情况就不要再手动删目录了，直接让 nvm 卸载：

nvm uninstall 18.20.4

如果你不知道当前用的是哪个版本：

nvm list nvm current

如果用的是n这个工具，卸载对应版本用：

sudo n rm <版本号>

这里特别提醒：nvm 管理的 node 安装在用户目录的.nvm目录下，路径通常是~/.nvm/versions/node/v18.20.4/。如果你跳过 nvm 命令直接rm -rf，会导致 nvm 的目录结构和记录文件不一致，后面再nvm list就会看到一堆无效版本号，反而是给自己挖坑。

3.4 别忽略两处共有残留

无论哪种方式装的，最后都建议检查两个位置：

• ~/.npmrc：npm 配置文件，残留的源地址可能让你后续安装依赖时连错仓库。
• ~/.node_repl_history：Node 交互命令行的历史记录。

这两个文件不影响新版本运行，但留着心里膈应，删掉也无妨。

另外如果你是 macOS 用户且用 Homebrew 安装过，卸载命令是brew uninstall node，清理逻辑和 CentOS 大同小异，这里不展开。

4. 重新安装前的版本决策：别再闭着眼睛装 LTS

卸载干净之后，下一步不是立刻冲去官网点下载，而是先想清楚一个问题：这次我要装哪个版本？很多人听说“LTS 稳定”就无脑装最新 LTS，但不同项目对 Node 版本的要求完全不同，这一步选错，后面的坑会接踵而至。

4.1 LTS 和 Current 到底怎么区分

Node.js 的版本发布有一套固定节奏：

• 偶数版本（如 18、20、22）进入长期支持期，也就是 LTS，适合生产环境和大多数业务项目。
• 奇数版本（如 21、23）属于 Current，只有短期维护，主要给想尝试新特性的人用，不建议放在生产环境。
• 每个大版本内部还会持续推送补丁版本，比如 18.20.4、22.12.0 这类小版本号，修复安全漏洞和 bug。

一句话总结：日常开发和生产部署选偶数 LTS；想提前体验新 API、不介意隔几个月升一次级的，可以追 Current。

4.2 18.20.4 LTS 和 22.12+ 怎么选

热搜词里同时出现了 18.20.4 和 22.12+，说明这两个版本是目前使用率最高的两条线。我的建议是这样：

另外给一个判断标准：打开你的项目package.json，看看 dependencies 里有没有老旧原生模块，比如node-sass、sharp旧版本。有的话，装新 Node 大概率要折腾编译链，老老实实装回项目开发时用的版本最省事。

4.3 一个治本的建议：用 nvm / nvm-windows 管理版本

说句心里话，这篇文章讲的是“卸载重装”，但如果你以后还会频繁换 Node 版本，我更推荐一步到位用版本管理工具解决。

• Windows 上用nvm-windows。
• Linux / macOS 上用nvm。

以 nvm-windows 为例，装好之后你不需要再从官网下载安装包，只需要：

nvm install 18.20.4 nvm use 18.20.4

以后想换版本就nvm install 22.12.0加nvm use 22.12.0，不会再出现“卸载不干净”的问题。这也是我从那次帮同事排查之后，给自己所有新环境配上的一套标准方案。

5. Windows 重新安装实操：msi 向导里这 5 步值得停下来想一想

确认好版本之后，正式进入安装环节。下面以 Windows 安装.msi安装包为例，把每一步的实际界面和相关选择讲透。

5.1 下载渠道：官网和国内镜像怎么选

首选官网 https://nodejs.org/en/download ，找到你要的版本，Windows 安装包选.msi后缀。如果你所在的网络访问官网较慢，可以用国内镜像站 https://npmmirror.com/mirrors/node/ ，目录结构跟官方一致，挑对应版本号的.msi文件下载即可。

我在实际下载时遇到过一个问题：从镜像站下载的文件有时没有文件扩展名后缀（比如文件名是node-v18.20.4-x64.msi但下载后变成一个无后缀文件），这时候手动补上.msi后缀就能正常打开。

5.2 安装路径要不要改

双击.msi进入向导，欢迎页面直接点 Next，接受协议后进入安装路径选择。默认路径是C:\Program Files\nodejs。

我的建议是：除非你有明确理由，否则保留默认路径。原因有两个：其一，默认路径在 PATH 里的引用方式被各种教程和图例反复验证过，出了问题好排查；其二，很多工具和 IDE 会默认去这个位置寻找 Node 可执行文件，改了路径以后它们可能连不上。如果你确实想换 D 盘，请确保整个路径中不要出现中文和空格，否则某些编译类工具会直接报错。

5.3 四个组件勾选和 Add to PATH

安装向导会进入自定义组件选择页，默认会勾选：

• Node.js runtime
• npm package manager
• Online documentation shortcuts
• Add to PATH

前面三项怎么勾都行，第四项Add to PATH 一定要保留。这一项决定你在任意终端窗口敲node -v能不能直接被识别。如果不勾，安装完成后你得手动配置环境变量，那种痛苦我经历过一次，替你避坑了。

5.4 “Automatically install the necessary tools”到底装什么

这是很多新手最容易困惑的一步，界面文字大概是“optional”旁边有一个复选框：Install the necessary tools to build native modules。

这个选项的用处是：通过 chocolatey 自动安装 Python 和 Visual Studio Build Tools，让你后续能编译node-gyp之类的原生模块。如果你的工作会接触到bcrypt、sharp、node-sass这类需要编译 C++ 的 npm 包，建议勾上；如果只是写点简单的接口和脚本，这个几千兆的编译工具链就大可不必勾选了。

注意这里有一个使用体验问题：勾选这一项后，安装过程完成会自动弹出一个新的管理员窗口，去装 chocolatey，网速不好的话会卡很久。我自己的习惯是第一次安装先不勾，等真正遇到原生模块编译问题，再用管理员终端单独安装编译工具，省时省力。

5.5 装完必须重新打开终端验证

安装完成后，请务必重新打开一个新的终端窗口，再执行：

node -v npm -v

如果你用的是已经打开的旧终端，PATH 不会自动刷新，看到的可能还是“node 不是内部或外部命令”的报错，这不代表安装失败，换个新窗口再试。

6. CentOS 7.9 用二进制包安装：一条命令搞定但有三处易错

Windows 讲完，回到 CentOS 7.9。如果你想在新环境里安装 Node.js，我推荐用官方二进制包，而不是走 yum——因为 CentOS 7 自带的 Node 版本实在太老，装完大概率会发现项目跑不起来。

6.1 下载、解压、做软链接的完整过程

先选定版本，比如 18.20.4。在/usr/local目录下操作：

cd /usr/local wget https://npmmirror.com/mirrors/node/v18.20.4/node-v18.20.4-linux-x64.tar.xz tar -xJf node-v18.20.4-linux-x64.tar.xz mv node-v18.20.4-linux-x64 nodejs

mv这一步是可选的，把目录名改成nodejs更清爽。随后建立软链接，让node、npm、npx命令全局可用：

ln -s /usr/local/nodejs/bin/node /usr/local/bin/node ln -s /usr/local/nodejs/bin/npm /usr/local/bin/npm ln -s /usr/local/nodejs/bin/npx /usr/local/bin/npx

最后验证：

node -v npm -v npx -v

三个命令都能输出版本号，说明安装成功。

6.2 易错点一：解压参数写错

很多人在执行tar -xJf时误写成tar -xzf。这两个参数看起来差不多，但压缩算法完全不同：.tar.xz需要的是-xJf（大写 J），写成-xzf会直接报tar: Cannot open: Not a gzip file。如果你下载的版本后缀是.tar.gz，那才用-xzf。下载前先看清文件后缀，别一股脑套命令。

6.3 易错点二：软链接漏掉 npm 和 npx

有人只给node做了软链接，然后执行npm -v报 “command not found”，慌慌张张以为自己安装失败。其实不然，问题是 npm 可执行文件就在解压目录里，但没有被链接到/usr/local/bin。处理方式就是对npm、npx、以及新版自带的corepack都补齐软链接：

ln -s /usr/local/nodejs/bin/corepack /usr/local/bin/corepack

6.4 易错点三：CentOS 7 老依赖链问题

CentOS 7.9 自带的 OpenSSL 版本相对较老，碰到某些需要新版加密库的 npm 包，编译时会报错。如果在安装canvas、argon2这类依赖时遇到 openssl 相关的错误，优先考虑升级系统库或改用 Docker 容器隔离环境，而不是反复重装 Node——问题往往不在 Node 本身。

7. 新环境必须做的三件初始化：全局目录、镜像源、快速验证

Node 装好并不代表万事大吉，我每次重装完都会顺手做三件事。这几步能避免后续使用过程中 80% 的“怪问题”。

7.1 自定义 npm 全局安装目录（主要针对 Windows）

Windows 上，全局安装的命令行工具默认会被丢到AppData\Roaming\npm。这个路径不是不行，但如果你希望全局工具集中管理、方便备份，可以在新环境里改一下 prefix。

创建一个你想用来存放全局工具的目录，比如D:\nodejs\global，然后执行：

npm config set prefix "D:\nodejs\global"

随后把这个新目录也加入 PATH 环境变量，这样以后npm install -g的工具都会集中到这个目录，想备份、想清理都很方便。Linux 上一般不需要改 prefix，保持/usr/local即可。

7.2 设置 npm 镜像源

国内访问 npm 官方源的体验时好时坏，重装后我第一件事就是把 registry 切到国内镜像：

npm config set registry https://registry.npmmirror.com

验证是否生效：

npm config get registry

输出https://registry.npmmirror.com/即可。

需要注意，如果你同时使用了 nvm 这类工具，npm 配置是跟随当前 Node 版本的。也就是说切换版本后可能又要重新设置一次镜像源，不用慌，重新执行一遍上面的命令就好。

7.3 完整验证清单：不只是看一眼版本号

node -v和npm -v只是最基础的验证。我更推荐创建一个临时脚本，模拟一次真实的包下载和运行过程：

npm init -y npm install dayjs node -e "const d=require('dayjs'); console.log(d().format('YYYY-MM-DD'))"

能正常输出日期，说明不仅仅是命令可用，npm 拉包、模块解析、Node 进程执行这条完整链路都是通的。这一步虽然多花两分钟，但能提前暴露不少环境配置问题，比如全局目录权限不对、镜像源连不通、node 和 npm 版本不匹配等等。

8. 重装后最常见的 4 个报错：从现象到根因的排查顺序

就算你看完了上面所有步骤，实际操作中也难免碰到报错。这里我整理了重装后出现频率最高的四个问题，按“现象 → 原因 → 解法”的顺序给你一条可复现的排查路径。

8.1 “node 不是内部或外部命令” / “command not found”

这是重装后最常见的第一道坎。出现这个提示，不要先怀疑安装包，先按顺序自查：

1. 确认终端是重装完成后新开的窗口，而不是旧窗口。
2. 在 Windows 上检查 PATH 是否包含 Node 安装目录，在 Linux 上执行which node看软链接是否存在。
3. 如果是 Linux，检查/usr/local/bin/node这个软链接是否指向真实存在的文件：ls -l /usr/local/bin/node。

很多次这个报错的根源其实就是 PATH 里的旧路径残留，或者你安装时手滑取消了 Add to PATH 勾选。解决方案就是把路径对齐，重新加进 PATH。

8.2 npm 版本还是旧的 / 全局包加载的是旧路径

如果你重装之后node -v已经是新版本，但npm -v显示的版本号依然很老，多半是 PATH 里同时存在新旧两个 npm 入口。Windows 上常见的情况是：老版本卸载不干净，%AppData%\npm里的 npm 脚本还在，而且这个路径排在安装目录前面，导致系统每次优先执行旧脚本。

排查命令是：

where npm

输出里如果有两条以上路径，把旧的删掉。Linux 同理：

which -a npm

对症处理完，重新开终端验证即可。

8.3 EPERM 操作被拒绝 / EACCES 权限不足

Windows 上出现 EPERM，最常见的原因是安装全局包时终端没有以管理员身份运行。第二步是检查是否有其他进程占用了 node_modules 里的文件——尤其是开了 VSCode 或正在运行中的 node 进程。任务管理器里把所有 node.exe 结束掉再重试，基本能解决。

Linux 上出现 EACCES，通常是因为全局模块目录的属主不是当前用户。不要习惯性用sudo npm install -g来解决，这会越搞越乱。正确做法是确认/usr/local/lib/node_modules和/usr/local/bin的权限设置，或者干脆改用 nvm，把全局包都装进用户目录，从根上避免权限问题。

8.4 全局工具全部丢失

卸载重装后，npm正常了，但你之前安装的pm2、vue-cli、nest等全局工具全都不见了。这是正常的——它们都存在旧环境里，清理残留时已经被删掉。

我的建议是，重装之前先保留一份全局包清单：

npm ls -g --depth=0 > global-packages.txt

重装完成后，打开这个文件，按需把需要的工具再装回来。为了避免以后每次升级或重装都重复造轮子，你还可以把自己常用的全局工具固定写在一个自己的“初始化脚本”里，之后跑到新机器上直接批量安装。

最后分享一个我自己的小习惯：凡是需要用 Node 开发的工作机，我都不再直接装官方安装包，而是统一用 nvm/nvm-windows 管理。这样版本切换不再是“卸载一个、装另一个”，而是nvm use一条命令的事，也就不会再有“卸载不干净”的烦恼了。如果你今天只是遇到了一个环境问题，希望这篇文章能帮你一次性把它解决；如果你想彻底告别这类问题，那我真心建议你开始使用版本管理工具。