企业官网建设流程全解析

如果你在搜索引擎里输入"nodejs 安装"，大概率会看到两个高频问题：一个是安装完成后 node 命令不被识别，另一个是 npm 命令在 PowerShell 里被拦下来，提示"无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本"。这两个问题几乎是 Windows 用户装 Node.js 的必经关卡，我在新电脑上重装环境时也会偶尔再碰上。

这篇文章就是把我自己的完整操作过程整理成一份可复现的笔记，覆盖从下载安装、环境变量配置、版本验证，到解决 npm.ps1 执行策略报错，再到全局模块目录重定向的完整链路。适合两类读者：一类是刚接触 Node.js 的新手，照着做就能把环境跑通；另一类是已经装了但被各种报错卡住的老手，可以直接跳到你关心的那一段对号入座。文章里的命令我都验证过，按顺序执行基本不会出问题。

1. 装之前先弄清这几件事，能少走一半弯路

1.1 Node.js 不是一门框架语言，而是一个 JavaScript 运行时

很多人一听到 Node.js 会下意识把它归类为"前端框架"，这其实是个常见误区。Node.js 的本质是一个建立在 V8 引擎之上的 JavaScript 运行时环境，它让 JavaScript 可以脱离浏览器运行在操作系统层面，从而有能力处理文件读写、网络请求、进程管理等传统后端语言擅长的事情。

理解这一点有什么实际意义？它会决定你后面怎么理解 npm。npm 是 Node.js 自带的包管理器，它的作用类似手机上的应用商店：别人写好并发布到 npm 仓库里的 JavaScript 模块，你通过一条 npm install 命令就能下载到本地，并在自己的项目里直接引用。现在的大部分前端工程化工具、后端服务框架，包括很多 CLI 工具，都是基于 Node.js 运行的。所以装好 Node.js 其实是在给你的电脑装一个能运行各类 JavaScript 工具的底座。

1.2 LTS 与 Current：长期维护版还是尝鲜版

打开 Node.js 官网首页，会看到两个明显的下载按钮：LTS 和 Current。LTS 全称 Long Term Support，翻译过来是长期支持版，官方会对这类版本提供长达数年的持续维护，包括安全修复和关键缺陷修补，生产环境里跑的基本都是 LTS。Current 则是最新功能版本，会先行获得新特性，但稳定性相对没那么有保障，频繁刷新新版本也容易带来兼容性变化。

给一个简单的选择建议：不需要犹豫，直接下 LTS。除非你有明确的新 API 或新语法必须依赖 Current 版本，否则对于学习、开发、搭建本地环境来说，LTS 是最稳妥的选择。我自己早期图新鲜装过 Current 版本，结果一个全局工具因为依赖的某个原生模块还没跟上新版本，导致编译失败，花了不少时间排查。装了 LTS 之后这类问题几乎没再出现过。

1.3 安装方式怎么选：官网安装包、nvm 还是包管理器

安装 Node.js 主要有三种方式，我按推荐度从高到低说一下。

第一种是官网安装包，下载 .msi 文件双击安装，适合绝大多数用户，也是这篇文章主线采用的方式，优点是最直观、可控，安装过程能看到每一步在做什么。

第二种是通过 nvm-windows 安装，nvm 是 Node 版本管理器，它能让你在一台电脑上同时保留多个 Node 版本，需要时随时切换。如果你经常需要维护多个旧项目，或者想体验新版本又不想影响现有环境，建议直接考虑这种方式。装了官网包之后再改用 nvm，反而要多一次卸载清理。

第三种是使用 winget、choco、scoop 这类包管理器安装，适合平时习惯用命令行管理软件的人。比如 winget install OpenJS.NodeJS.LTS 就能一键装好 LTS 版本，优点是升级方便，缺点是对系统环境变量的控制没那么直观。第一次接触 Node 的读者，我建议先走第一种方式，等对全局路径、环境变量这些概念有体感之后，再去尝试 nvm 做版本管理。

2. 下载安装全流程：每一个勾选框都要看懂再动

2.1 官网下载入口和各版本对应关系

官网地址是 nodejs.org 或者直接搜"Node.js 官网"，进去之后首页通常有两个大按钮：左侧标着 LTS，右侧标着 Current。点击对应按钮会下载对应版本的系统安装包。这里有一个经常被忽略的细节：官网首页会自动识别你当前的操作系统并给出版本号，但如果你在 Windows 上使用，还是建议点进官网的下载页面，确认下载的是 Windows 安装包（.msi），而不是 Linux 的 tar.gz，或者 macOS 的 pkg 安装包。

2.2 安装向导中的关键选项

双击 .msi 进入安装向导之后，一路 Next 也可以装完，但我建议你在几个关键位置看一下。

第一个是安装路径。默认路径是 C:\Program Files\nodejs\，如果电脑 C 盘空间紧张，或者你不想让 npm 全局模块和程序本体混在一个受保护的系统目录里，可以在这一步自定义路径。建议确保路径里不要出现中文和空格，比如 D:\nodejs\ 就很干净，后面配环境变量时会省很多麻烦。

第二个是"Add to PATH"勾选框，在 Custom Setup 页面里可以找到，这里一定要勾选。它的作用是把 Node.js 的可执行文件目录写进系统环境变量，这样你在任何终端窗口里都能直接执行 node 命令。很多人安装完以后发现 node 命令不可用，第一步就要检查这里是不是被取消了勾选。

第三个是接下来的 Tools 选项，安装向导会询问你是否安装编译原生模块所需的工具链（比如 Python 和 Visual Studio Build Tools）。如果你是纯前端开发或者只用现成的 npm 包，可以跳过；但如果你计划安装 node-sass、bcrypt 这类需要本地编译的模块，建议后续按需再补，不要在安装向导这一步浪费太多时间。

2.3 装完就打开的终端，为什么还是找不到 node

这是非常典型的一个现象：安装过程一切正常，向导最后显示 Finished，然后你立刻打开一个终端窗口敲 node -v，结果提示"node 不是内部或外部命令"。我第一次遇到时甚至以为安装包坏掉了，重新下载装了一遍，结果还是一样。

原因其实和 Windows 的环境变量刷新机制有关。系统在每次进程启动时读取环境变量，而终端窗口是在安装前打开的，它缓存的是旧的环境变量快照，根本不会感知到安装过程新加入的 PATH 条目。解决方式也很简单：把当前终端窗口关掉，重新开一个新的，让新进程重新读取系统环境变量。如果你是先打开终端再安装的程序，这一步几乎必踩。另外，如果重开终端仍然不行，那就要进入下一节说到的环境变量检查流程了。

3. 环境变量配置：教系统去哪里找 node

3.1 PATH 的工作机制

可以把 Windows 系统理解成一个大型图书馆，你输入命令时，系统就像图书管理员拿着索引去找对应的书。PATH 环境变量就是这份索引，里面按顺序列出了若干个目录。当你输入 node -v 时，系统会逐个去 PATH 列出的目录里寻找名为 node.exe 的可执行文件，找到就运行，找不到就提示"不是内部或外部命令"。

这个机制解释了为什么很多初学者觉得"我明明装了呀，为什么系统不知道"：安装程序只是把文件放到了某个目录里，但如果没有把这个目录告诉 PATH，系统就根本不会去那个目录里找。顺着这个思路下来，所谓"配置环境变量"其实就是把 node.exe 所在目录加到 PATH 里去。

3.2 手动配置 NODE_HOME 与 PATH 的完整步骤

虽然正常情况下安装向导已经帮你把 PATH 配好了，但如果你遇到 node 命令不可用的情况，或者安装路径过于特殊导致自动配置失效，就需要手动配置。按下面步骤操作：

1. 按 Win 键，搜索"编辑系统环境变量"并打开，点击右下角"环境变量"按钮。
2. 在"用户变量"区域点击"新建"，变量名填 NODE_HOME，变量值填你的 Node.js 安装目录，比如 D:\nodejs。使用用户变量只对当前用户生效，个人开发电脑完全够用，不用去动系统变量。
3. 在"用户变量"中找到 Path，双击打开，点击"新建"，添加一行 %NODE_HOME%。把路径写成变量形式，以后如果更改安装目录，只需要改 NODE_HOME 一个地方即可。
4. 点击"确定"保存所有窗口，然后重新打开一个终端。

这里有个细节：新增条目推荐放在最前面。因为系统会按 PATH 里目录的排列顺序逐个查找，如果在 C:\Windows\System32 之后又存在一个同名工具，先找到谁就执行谁。把 Node 的目录放前面，可以避免被同名文件干扰。

3.3 验证环境变量生效的三个命令

配置完之后，在终端里依次执行下面三条命令：

node -v npm -v echo %NODE_HOME%

第一条输出 v18.20.x（具体版本号取决于你的安装版本）说明 node 主体正常；第二条输出对应 npm 版本号；第三条输出你配置的安装目录路径。如果三者都正常，说明环境变量已经生效。

如果 echo %NODE_HOME% 输出的是变量名而不是展开后的路径，说明当前终端还没有重新加载环境变量，关掉重开一个即可。如果使用 PowerShell，可以用 $env:NODE_HOME 查看，也能用 where.exe node 看到系统找到 node 的完整路径，进一步确认 PATH 排列顺序是否正确。

这三个命令可以作为以后排查所有"命令找不到"问题的标准三板斧：先看变量有没有定义，再看命令能不能找到，最后看版本能不能跑起来。

4. 安装完成后的验证：node -v 只是第一关

4.1 版本命令和它们背后的含义

node -v 输出的是 Node.js 引擎版本，npm -v 输出的是包管理器版本。这两个版本号是独立的，Node 大版本升级时 npm 不一定跟随同版本号，所以看到两者数字不一样不要慌，这很正常。

另外建议顺手看一下 npx -v，npx 是 npm 5.2 之后附带的一个工具，它的作用是可以直接运行项目里 node_modules/.bin 下的命令，而不用先把工具全局安装。很多前端项目脚本都是靠 npx 来执行的，确认它在，后面用起来就不用临时补装。

4.2 用 REPL 模式快速跑一段 JavaScript

版本号能输出并不代表运行时完全正常，我习惯顺手做一次真实执行测试。在终端里直接输入 node，不带任何参数，会进入 REPL 模式，一个可以直接交互执行 JavaScript 的终端环境。输入下面的代码然后回车：

1 + 2

终端会立刻输出 3。再试试定义变量：

let msg = "hello nodejs"; console.log(msg.toUpperCase());

输出 HELLO NODEJS，说明运行时、控制台输出、字符串 API 都正常。按两次 Ctrl+C 或者输入 .exit 退出 REPL。

这一步在刚装完环境时非常重要，因为部分安装包缺损会在真实执行时才暴露问题，而版本命令往往显示正常。

4.3 真实场景：写第一个脚本文件并运行

REPL 适合随手验证，真正干活还是要写脚本文件。新建一个目录，比如 D:\work\hello-node，在里面创建 index.js，写入以下内容：

const http = require('http'); const server = http.createServer((req, res) => { res.writeHead(200, { 'Content-Type': 'text/plain' }); res.end('Hello Node.js'); }); server.listen(3000, () => { console.log('Server running at http://localhost:3000'); });

然后在终端里切到该目录并执行：

node index.js

看到 Server running at http://localhost:3000 后，打开浏览器访问 http://localhost:3000，页面会显示 Hello Node.js。这一步能跑通，说明 Node.js 的模块加载、网络监听、事件回调整套机制都正常，环境配置可以说真正完成了。

记得跑完后在终端按 Ctrl+C 停掉服务，别让它一直占着 3000 端口。

5. npm.ps1 无法加载文件：Windows 执行策略的完整排查

5.1 错误在什么情况下出现

这是 Windows 用户最常见的 Node 环境报错之一，完整提示是：

npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。有关详细信息，请参阅 https:/go.microsoft.com/fwlink/?LinkID=135170 中的 about_Execution_Policies。

出现时机一般有两个：一是在 PowerShell 里执行 npm、npx 这类命令时；二是执行某些 npm 脚本时。有个很典型的特征是，换到 CMD 里执行 npm -v 又完全正常，这就是为什么很多人会怀疑是 PowerShell 出了问题。

5.2 根因：PowerShell 执行策略的默认限制

根本原因不在 Node 本身，而在 PowerShell 的安全机制。npm 在 Windows 上的可执行入口是一个 .ps1 脚本文件（PowerShell 脚本），位于 C:\Program Files\nodejs\ 目录下。当你在 PowerShell 里输入 npm 时，实际执行的是 npm.ps1，而 Windows 为了防范恶意脚本，默认对脚本执行做了限制，即"执行策略"（ExecutionPolicy）。

执行策略按作用域划分，包括 MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine 几个层级，限制由严到松。在大多数 Windows 客户端默认设置下，Restricted 或 Undefined 策略会让 PowerShell 拒绝运行任何 .ps1 脚本。这就相当于：系统知道命令存在，但出于安全策略拒绝执行它。CMD 不受这个策略影响，因为它直接运行的是 npm.cmd 而不是 .ps1 脚本。

想确认当前执行策略，在 PowerShell 中运行：

Get-ExecutionPolicy -List

输出结果中每一个作用域对应一列值，如果 CurrentUser 和 LocalMachine 都是 Restricted 或 Undefined，就解释了你遇到这个问题。

5.3 修复方案：按安全等级选择

最简单的修复是只对当前用户放开限制，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

系统会要求确认，输入 Y 回车即可。RemoteSigned 的含义是：本机创建的脚本可以运行，从网络下载的脚本必须有可信发布者签名才能运行。这个等级能覆盖日常开发的大部分场景，同时保留了对外部下载脚本的拦截，属于兼顾安全性和便利性的选择。设置完成后再次运行 Get-ExecutionPolicy，看到 RemoteSigned 即表示成功。

如果是在公司电脑或者安全要求较高的环境，建议只设置 CurrentUser 作用域，不要贸然改 LocalMachine，这样只影响当前 Windows 用户，不影响其他账户。

5.4 修复后的验证

执行完上面的命令后，在当前 PowerShell 窗口运行：

npm -v

如果正常输出版本号，问题解决。如果仍然报同样的错，检查一下当前窗口是否处于管理员身份，或者有没有通过组策略锁死执行策略，可以再运行 Get-ExecutionPolicy -List 确认每个作用域的最终策略。

5.5 不想改全局策略怎么办：三个平替方案

如果你出于安全原因不想修改执行策略，还有三个办法可以不用改全局设置。

第一，改用 CMD。在开始菜单搜索"命令提示符"，在里面执行 npm -v，因为 CMD 直接调用 npm.cmd，不经过 PowerShell 的脚本策略。

第二，在 PowerShell 里显式调用 npm.cmd，即每次输入 npm.cmd 而不是 npm。缺点是每次都多打几个字母，容易忘。

第三，针对单个命令使用绕过策略执行。比如：

powershell -ExecutionPolicy Bypass -Command "npm -v"

这条命令会新开一个临时 PowerShell 进程，用 Bypass 策略跑完命令就退出，不便的是每次写起来比较长。

整体来说，我个人的习惯是直接设置 CurrentUser 的 RemoteSigned。从风险角度看，RemoteSigned 对外来脚本仍有签名校验，日常开发场景属于可接受的安全级别。真正需要注意的反而是另一个问题：不要图省事直接把执行策略设为 Unrestricted，那会完全关闭脚本安全检查，尤其在公司电脑上，风险会大很多。

6. 给 npm 搬家：全局安装目录与缓存目录配置笔记

6.1 查看 npm 当前全局安装位置

npm 安装的包分两类：项目依赖装在项目目录下的 node_modules 里，而通过 npm install -g 安装的全局工具，会统一放在一个"全局目录"里。这个全局目录在 Windows 上默认是当前用户目录下的 AppData\Roaming\npm，具体可以通过命令确认：

npm config get prefix

最常见的情况是输出 C:\Users\你的用户名\AppData\Roaming\npm。同时可以查看缓存目录：

npm config get cache

输出一般是 C:\Users\你的用户名\AppData\Local\npm-cache。

6.2 为什么要让 npm 把模块装到自定义目录

很多人初期并不在意全局路径，用着用着就会遇到三个问题。

第一是权限问题。如果你把 Node 装到了 Program Files 目录，而全局工具又想写到系统保护目录，Windows 的 UAC 会频繁弹窗要求管理员权限。第二是清理问题。卸载 Node.js 时，全局安装的工具和缓存分散在 AppData 里的多个位置，不删干净就会留下大量残留。第三是管理问题，自定义目录更直观，备份和迁移都方便。尤其是当你经常重装系统或更换电脑时，只要备份一个放全局模块的目录，装好新环境之后重新设置一下路径就能继续用。

6.3 修改 prefix 和 cache 的完整操作

在 PowerShell 中执行：

npm config set prefix "D:\nodejs\npm_global" npm config set cache "D:\nodejs\npm_cache"

这两条命令会修改当前用户的 .npmrc 配置文件。可以用下面的命令确认：

npm config get prefix npm config get cache

设置完成后，需要把全局模块目录加入 PATH，否则以后用 npm install -g 安装的全局命令会提示"不是内部或外部命令"。找到环境变量编辑界面，和前面配置 NODE_HOME 一样，在 Path 里新增一行 D:\nodejs\npm_global。

用 -g 安装一个工具验证一下，比如：

npm install -g yarn yarn -v

如果能正常输出版本号，整个搬家流程就算成功了。以后所有全局工具都会装到 D:\nodejs\npm_global 里，查看和清理都非常方便。

这些命令最终会写进用户目录下的 .npmrc 配置文件。如果你喜欢手动维护，也可以直接编辑 .npmrc 添加对应配置，但我更推荐用 npm config set，因为命令会帮你校验参数格式，不容易出现引号或编码问题。

6.4 全局模块命令找不到的排查顺序

如果你的全局命令安装成功但运行时找不到，不要直接重装，按下面顺序排查：先执行 where 命令名 或 Get-Command 命令名，看系统有没有找到这个命令；如果没有，检查 npm config get prefix 的输出是否是你设置的目录；再检查 PATH 里是否包含这个目录；最后确认当前终端是否是在配置完 PATH 之后打开的。绝大多数全局命令找不到的问题都能在这几步里解决。

7. 维护笔记：多版本切换、升级与彻底卸载

7.1 用 nvm-windows 同时装多个 Node 版本

如果你经常需要维护不同历史时期的项目，就会发现有些旧项目必须用 Node 14，而新项目要用 Node 20，单纯装一个版本根本不够。这时候推荐使用 nvm-windows，它是 Node 版本管理器，允许你在多个版本之间随意切换。

安装 nvm-windows 之前，建议把现有 Node 版本卸载干净，避免和 nvm 托管的环境变量冲突。然后从 nvm-windows 的 GitHub Releases 页面下载 nvm-setup.exe，一路安装即可。nvm 会接管 node 命令的指向，你只需要执行：

nvm install 18.20.4 nvm install 20.11.1 nvm use 20.11.1

nvm 会自动切换到指定版本。用 nvm ls 可以查看已安装的版本列表，nvm current 查看当前使用的版本。装过 nvm 之后再想改全局模块目录，思路和前面一样，只是路径要改到 nvm 对应的目录下，原理完全相同。

7.2 npm 与 Node 如何升级

Node 自身版本升级，如果当初用的是官网安装包，就直接去官网下载新版本覆盖安装，一般不需要卸载旧版本。但计划重大版本跨度升级时，建议先备份全局模块列表，避免某些工具在安装新版本后丢失。

npm 自身升级比较特殊，它作为 Node 内置包，会被 Node 版本约束。常用命令是：

npm install -g npm@latest

升级前可以用 npm -v 确认当前版本，升级后再次确认。如果提示权限错误，检查当前用户是否有全局目录的写权限，或者是否自定义过 prefix 目录。

7.3 卸载 Node.js 时最容易漏掉的残留

卸载 Node 也不只是控制面板里点一下卸载那么简单。卸载完成后，建议手动检查以下几个位置：

• 安装目录（默认 C:\Program Files\nodejs 或你自定义的目录）
• 用户目录下的 .npmrc 配置文件
• 全局模块目录（默认 %APPDATA%\npm，或你自定义的目录）
• 缓存目录（%APPDATA%\npm-cache 和 %LOCALAPPDATA%\npm-cache）
• 环境变量里残留的 NODE_HOME 和 Path 条目

把这几处清理干净，才算真正卸载完。我见过不少同事因为残留的 .npmrc 指向一个已不存在的目录，导致新环境安装后全局命令怎么都跑不起来，排查半天才发现是旧配置在作怪。

每次重装完 Node 环境之后，我都会花三分钟做一次固定检查：node -v、npm -v、npm config get prefix、npm config get cache。确认这四个输出都符合预期，再把执行策略设置好，整个环境就是干净的、可预期的，后面折腾项目的时候能少踩一大半坑。