ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

Windows下Node.js v14.15.1安装配置与nvm多版本管理实践指南

Windows下Node.js v14.15.1安装配置与nvm多版本管理实践指南 简介node-v14.15.1-win-x64 是面向 Windows 64 位平台的 Node.js 长期支持版本为开发者提供完整的 JavaScript 服务端运行环境。它内置 V8 引擎和非阻塞 I/O 模型适合构建高并发的 Web 服务、命令行工具及自动化脚本。压缩包内含约 2000 个文件其中 js 文件为核心模块与库代码md 文档提供使用说明json 包含配置信息另有少量 Python 脚本与 HTML 辅助页面全部打包后仅 27.45MB下载部署十分轻便。作为 LTS 版本它享有更长时间的安全更新与官方维护适合企业项目稳定落地。包中包括 node.exe 解释器、npm 包管理器及必要的头文件与核心库解压即可使用配合 Express、Webpack 等生态工具能极大提升后端开发效率。已有 336 人学习下载对希望在 Windows 平台搭建可靠 Node 开发环境的开发者来说是省心且高效的选择。 看到 node-v14.15.1-win-x64 这个文件名凡是在 Windows 64 位环境下搞过 Node.js 开发的朋友应该都不陌生。这就是 Node.js 官方发布的 14.x LTS 线在 2020 年 11 月的一个具体版本安装包。我到现在还留着这个安装包因为不管后来 Node 版本怎么迭代很多老项目、企业内网和生产环境里v14.15.1 的出镜率依然非常高。这篇文章不打算只教你点“下一步”而是把我从下载安装、环境变量配置、nvm 多版本管理到跑真实项目时踩过的那些坑系统地梳理一遍。内容适合两类人一是刚接触 Node、准备在 Windows 上搭建开发环境的新手二是需要在内网、离线环境部署特定 Node 版本的老手。读完你能明白每个步骤背后的原因也能直接照做。1. 项目概述与版本选择1.1 node-v14.15.1-win-x64 到底是什么先把文件名拆开看node 是运行环境本体v14.15.1 是版本号win-x64 表示 Windows 64 位平台。这个版本属于 Node.js 14 主线14.x 是 2020 年 10 月进入 LTS长期维护状态的一条主干版本线官方维护期一直拉到 2023 年 4 月。v14.15.1 作为该主线上的稳定补丁版本属于“既新又稳”的典型代表相比 v12它正式支持了 ES2020 的很多特性比如可选链操作符 ?. 和空值合并 ??写起来舒服相比 v16、v18它又更保守对老旧项目的依赖兼容性极好。对应的安装包常见两种格式.msiWindows 安装程序双击走图形界面顺手帮你在系统 PATH 里写入可执行路径。.zip绿色解压包解压即用适合不想污染系统注册表、或者需要批量拷贝到多台机器上的场景比如内网分发。我在公司给离线环境部署 Node 时90% 的情况用的都是 .zip 解压包因为可以提前在一台机器上把依赖装好然后整个目录拷过去不需要每台机器都过一遍安装向导。1.2 为什么到今天还值得聊这个版本可能有人会问Node 都出到 20、22 了为什么还揪着 v14 不放这里我要说一个实际现象很多上了生产的老项目尤其是一些用 vue-cli 2/3、node-sass、老版 webpack 搭起来的工程它们的依赖锁死在一段很窄的 Node 版本区间。比如 node-sass 4.x 在 Node 14 下能正常编译拿到 Node 16 上就大概率报错。Electron 应用如果绑的是旧版内置 Node开发环境也得跟着对齐版本。当然全新项目我一般会建议直接用长期维护版里较新的主线比如当时是 v18/v20。但是“手上有一个老项目必须用 v14.15.1 跑起来”或者“内网机器只能保存这一个安装包”这种情况我遇到过太多次。所以这篇文章把 v14.15.1 当作一个具体样本来讲安装、配置、排错思路完全可以迁移到其他版本。2. 环境准备与安装实操2.1 下载安装包和校验下载渠道很简单Node 官网的发行包目录都按版本归档访问 nodejs.org/dist/v14.15.1/ 就能拿到所有平台的文件。选择 node-v14.15.1-win-x64.msi 或 node-v14.15.1-win-x64.zip 下载即可。这里有个小建议下载后在做分发或安装前先算一下安装包的哈希值防止文件在下载过程中损坏特别是内网用 U 盘拷贝的场景。Windows 下用系统自带的 certutil 就能算certutil -hashfile node-v14.15.1-win-x64.msi SHA256把输出和官方发布的 SHASUMS256.txt 文件对一下一致再继续。这个动作看起来多余但我在实际部署时遇到过两次安装包在拷贝过程中被截断导致的诡异报错比如“安装过程卡在 95%”或者“npm 内部模块找不到”都是哈希校验直接揪出来的问题。2.2 安装步骤MSI 和 ZIP 两种方式MSI 方式最简单双击后一路 Next但有两个地方建议手动处理一下安装路径默认装在 C:\Program Files\nodejs如果 C 盘空间紧张可以在安装界面的“Change”里改到 D:\nodejs。勾选项安装向导里有 “Add to PATH” 的选项务必保持勾选这个动作会把 node.exe 所在的目录加入系统 PATH否则安装完在命令行里敲 node 会提示“不是内部或外部命令”。ZIP 方式就是解压。我习惯把压缩包解压到 D:\nodejs然后目录结构大概是D:\nodejs\ node.exe npm.cmd npx.cmd node_modules\接下来手动把 D:\nodejs 添加进 PATH。这里需要区分一点MSI 安装会在系统变量里加一条ZIP 方式最好也加到“系统变量 Path”而不是“用户变量 Path”。原因是很多 IDE、终端工具以管理员身份或通过服务方式运行时会读取系统变量只配用户变量容易出现“命令行能运行 node但 IDE 里找不到”的怪问题。2.3 环境变量配置的完整思路配置环境变量的核心就一句话让系统能在任意路径下找到 node.exe 和 npm.cmd。我建议设置两个环境变量变量名变量值作用NODE_HOMED:\nodejs统一记录 Node 安装目录PATH追加 %NODE_HOME%;%NODE_HOME%\node_modules.bin让 node/npm/npx 全局可用其中 NODE_HOME 是一种约定俗成的环境变量名。别看它简单在后续做多版本切换、脚本调用 node 时非常有用很多部署脚本会读 NODE_HOME 来定位解释器。PATH 里追加 %NODE_HOME%\node_modules.bin 则可以覆盖一部分“全局命令行工具找不到”的问题因为很多全局包的命令都软链到这个目录。配置完以后重新打开一个命令行窗口依次执行node -v npm -v npx -v如果分别输出 v14.15.1、6.14.8、6.14.8npm/npx 随 Node 版本绑定说明环境已经通了。这里有个小坑改了环境变量后已经打开的 CMD、PowerShell 窗口不会自动刷新必须全部关掉重开否则很容易误以为配置失败。提示改完环境变量一定要重开终端这个动作能省掉一半的“环境没配好”的假报错。3. 进阶版本管理与全局配置3.1 为什么必须引入 nvm-windows装好一个 Node 版本只是开始。实际开发中最大的痛点是不同项目对 Node 版本的要求经常是冲突的A 项目锁死 v14B 项目要用 v16 才能跑全局工具链还可能要最新版。如果靠手动卸载重装来回折腾一次至少十分钟还容易留下环境变量残留。这个时候就需要 nvm-windows它是 Node Version Manager 的 Windows 版本专门用来自动下载、安装、切换多个 Node 发行版本。注意一个使用前提如果电脑上已经通过 MSI 装过 Node建议先把旧版卸载干净因为 nvm 管理的是它自己目录下的 Node和系统 PATH 里残留的旧 node.exe 冲突会产生“明明切换了版本一执行 node -v 还是老版本”的假象。3.2 用 nvm 安装和切换 nodeWindows 下选 nvm-windows 的 release 包常见是 nvm-setup.zip装完在命令行里验证nvm version之后所有操作都变得很干脆nvm install 14.15.1 nvm install 16.20.2 nvm use 14.15.1 nvm listnvm install 下载并安装指定版本版本号按官方列表写。nvm use 切换到对应版本这一步会改写 PATH 指向 symlink。nvm list查看本机已安装的所有版本当前使用版本前会有 * 号。我自己的习惯是用 nvm 安装 Node 之后不再手动设 NODE_HOME而是让 nvm 自己维护路径因为 nvm-windows 会在安装时接管全局 PATH。需要临时用某个版本跑脚本时就直接 nvm use xx比改全局变量干净得多。3.3 全局配置镜像源、全局目录、缓存环境通了之后第一件要做的全局配置就是 npm 镜像源。国内直连官方源下载依赖很慢换到 npmmirror原淘宝镜像是性价比最高的优化npm config set registry https://registry.npmmirror.com npm config get registry这个配置写进的是用户级的 .npmrc 文件路径在 C:\Users用户名.npmrc。除了镜像源我还会顺手把全局安装目录和缓存目录从 C 盘挪走npm config set prefix D:\nodejs\npm-global npm config set cache D:\nodejs\npm-cache全局目录单独建方便出问题时整体删除也不会污染 Node 安装目录。镜像源本身只是 HTTP 仓库没有任何网络代理的意思纯粹是下载节点使用起来安全放心。4. 实战运行第一个项目与常见错误排查4.1 验证环境后快速跑起一个项目装好环境总得跑点真东西。我习惯先用一个最简单的 HTTP 服务做冒烟测试。新建一个文件夹比如 D:\demo在里面建 index.jsconst http require(http); const server http.createServer((req, res) { res.end(node-v14.15.1 works); }); server.listen(3000);命令行进入目录执行node index.js浏览器打开 http://localhost:3000看到 works 字样就说明 Node 运行正常。如果要用 npm 管理依赖先 npm init -y 生成 package.json再 npm install 具体包。顺便说一下 node 和 npm 的区别node 是 JavaScript 运行时负责执行代码npm 是包管理器负责把别人写好的模块下载到本地并处理依赖关系。命令行里 node xxx.js 是跑脚本npm install 是装包两者配合才能构成完整的开发链路。测试 npm 是否正常我通常用npm install express -S装完再在页面里加一行需要 express 的代码能正常返回就说明 node 和 npm 链路都是通的。4.2 高频报错速查表实操里报错比成功更多见。这里整理我从 Windows 环境收到最多的一批报错和对应解法做成表格报错现象原因解决办法npm 不是内部或外部命令PATH 里没加 node 目录检查/重新配置 PATH重开终端node:internal/modules/cjs/loader:1568 throw err; Error: Cannot find module xxx项目依赖没装全或 NODE_PATH 不对在项目根目录执行 npm install确认模块名拼写Failed to execute insertBefore on Node浏览器里的 DOM 操作报错不是 Node.js 环境本身的问题检查前端代码通常和 DOM 节点插入顺序有关npm ERR! code CERT_HAS_EXPIRED老版本 Node 自带的 CA 证书过期访问镜像源报证书问题优先升级 Node 版本临时设置 strict-ssl false 应急vue-cli-service 不是内部或外部命令node_modules 损坏或未安装完整删除 node_modules 和 package-lock.json 后重装安装 node-sass 时编译失败node-sass 与当前 Node 版本不匹配切到匹配的 Node 版本或用 sass 替代用 Puppeteer 或 PHP 调用 node 时找不到执行路径系统级 PATH 没有配置 node 目录把 node 目录写进系统变量而不是只写用户变量JetBrains 系 IDE 里插件报 cjs/loader 1424插件内部进程找不到对应模块清理 IDE 缓存重装插件依赖检查系统 Node 路径其中 Cannot find module 是我个人遇到最多的。常见误区是只装全局包项目里照样报找不到因为 Node 模块解析是先从当前项目 node_modules 向上级一层层找全局包位于全局目录不是项目解析路径的范畴。遇到这种报错先看项目根目录有没有 node_modules再确认 module 名字有没有拼错最后才考虑全局安装。4.3 版本兼容性node-sass、node-gyp、Electron用 v14.15.1 跑老项目最常见的兼容性问题集中在原生模块编译上典型代表是 node-sass 和 node-gyp。node-sass 是依赖 Node ABI 的绑定Node 14 对应需要 node-sass 4.14如果你在 Node 18/20 上直接装 node-sass 4.x下载二进制时会报找不到对应版本此时要么锁到 v14要么把依赖替换成 sassdart-sass后者对版本兼容更宽。node-gyp 的问题则集中在 Windows 缺少编译链需要安装 Visual Studio Build Tools 的 C 模块同时确保 Python 按官方要求可用。很多时候用脚本或工具自动部署 npm 包时出现 gyp 编译错误根子都在这里。装齐编译链之后这类错误能消掉一大半。5. 场景延展除了搭环境Node 还能这样用5.1 用 Nuxt 做中间层Node 装好之后第一梯队能干的活就是写服务端和中间层。Nuxt 是 Vue 生态里非常流行的 SSR 框架它既能做服务端渲染又可以在中间层BFF里聚合多个后端接口为前端提供更友好的数据格式。这也是“node 使用 nuxt 做中间层”这类问题的典型场景。简单说前端请求先打到 Nuxt 服务Nuxt 再在 server 端转发到真正的后端 API顺便做鉴权、数据裁剪、字段拼装然后返回给页面组件。这样做的收益是前端只面向一套干净的数据接口后端也可以保持原样不动。中间层用 Node 跑 Nuxt天然和 Vue 技术栈统一开发时不需要切换语言。同样的思路也适合做纯 API 服务层。有些后台管理系统模板比如 Vue Pure Admin 这类前后端分离项目往往就是一个 Node 服务端负责读数据库、写接口前端页面只负责展示。这类项目只要把 Node 环境配好npm install 一次再写好数据库连接配置整个链路就能跑起来对新手来说是最容易上手的 Node 实战方式。5.2 内网离线环境部署回到 v14.15.1 最常出现的另一个场景内网离线安装。内网机器可能完全无法访问外网。这时候靠安装包装环境只是第一步依赖包怎么弄才是重头戏。我的做法是在能联网的机器上把项目 npm install 好然后把 node_modules 整个目录压缩拷进内网解压再通过 NODE_PATH 指定依赖位置运行。如果项目里有原生模块比如 node-sass务必在相同系统架构都是 win-x64的联网机器上装好否则二进制绑定不适用拷过去也跑不起来。同样的思路也适合 linux 环境下的离线 node 安装区别只是把安装包换成对应平台的 tar.xz 文件PATH 配置方法一致。windows 下还有一点要特别注意整目录拷贝时不要用压缩软件二次解压到带中文或空格的路径否则 npm 内部解析路径时容易出幺蛾子。结尾最后再分享一个心得Node 环境这东西最忌讳“装完就算”。我见过太多开发机上有三四个版本的 Node 残留全局包里几十个工具一跑项目就是各种诡异报错。干净的做法是普通开发尽量用 nvm 管理版本每个项目按 .nvmrc 锁版本全局包只装高频工具node_modules 出问题先删后装而不是反复修复。v14.15.1 这个包我不建议新项目去用它但如果你在维护老系统或者必须做内网部署它仍然是值得信赖的稳定底座。把安装、配置、切换、排错这套流程吃透以后换任何 Node 版本都只是在重复同样的动作而已。本文还有配套的精品资源点击获取
返回列表