简介这里提供的是 Node.js 官方发布的 v13.9.0 版本 Windows 64 位安装包主要面向需要在 Windows 系统上快速配置 Node.js 运行环境的开发者、学习者以及负责环境维护的运维人员。该版本属于 Node.js 13 系列的稳定维护版常被用于特定项目兼容、教学实验、依赖锁定以及本地调试等场景对后续更高的 Node.js 版本也有环境参照价值。安装包采用 zip 压缩格式整体大小约 26.84MB结构精简携带方便解压后即可配置使用无需额外安装组件同时可以拷贝到内网环境供离线安装节省等待官网下载的时间。目前该资源已有 753 人学习下载适合初学者搭建基础开发环境也适合工程师在版本切换时留存离线备份尤其是依赖特定版本 Node.js 的遗留项目维护能够保证运行时行为的一致性。下载后获得的是官方原版安装文件在此基础上可顺利完成 npm 包管理、Express 服务搭建、前端构建工具链调试等操作配合 nvm-windows 这类版本管理工具还能灵活切换多个 Node 版本有效提升日常开发、测试与排错效率是一份实用且值得收藏的基础资源包。 看到 node-v13.9.0-win-x64.zip 这个文件名如果你跟我当年第一次接触 Node.js 一样双击准备“安装”我先把丑话说在前面这是一个 zip 压缩包双击它什么都不会发生。它不是安装程序只是把 Node.js 的完整运行文件打了个包。你需要做的是把它解压到某个目录、手动配置环境变量然后才能在终端里真正用上 node 命令。如果你是从某篇老教程或者某个老项目的文档里翻出这个包的那大概率还连带一个问题为什么要用 zip 而不是 msi为什么是 v13.9.0 而不是 v18 或 v20这篇文章我不打算讲太多虚的就围绕这个包从安装、配置到版本管理的完整链路一步步说清楚顺便把我在 Windows 上折腾 Node 环境这几年踩过的坑一起倒出来。无论你是刚开始学前端、要跑 Node-RED 或 ComfyUI 这类工具还是公司老项目需要特定版本这篇都适用。1. 解构安装包版本号、平台和格式背后的信息1.1 文件名里的三组关键信息从 node-v13.9.0-win-x64.zip 这个文件名其实可以读出三组关键信息v13.9.0 是 Node.js 版本号13 是大版本9 是小版本对应功能变更0 是补丁版本对应问题修复。win-x64 是目标平台也就是 Windows 64 位操作系统。官方还会提供 win-x8632 位、linux-x64、darwin-arm64苹果 M 系列芯片等不同版本。zip 是打包格式。官方在 Windows 上提供 zip 和 msi 两种格式后者带图形安装向导。很多人第一次看到这一堆后缀就犯迷糊我明明用的是 Windows 电脑为什么下载页面里有一大排选项先记住一句话64 位系统选带 x64 的包32 位系统选 x86。近几年出厂的电脑基本都是 x64直接拿 x64 版本基本不会错。1.2 v13 是过渡版本不是 LTS为什么我特别强调 v13 这个版本号因为 Node.js 的版本线有一个非常明显的规律偶数大版本12、14、16、18、20是 LTS 长期维护版本官方承诺长时间的安全更新适合生产环境奇数大版本11、13、15、17是 Current 尝鲜版主要用于提前体验新特性维护周期短不适合指望它长期稳定运行。v13.9.0 属于 v13 这条奇数版本线放到现在的眼光看已经比较老了。但老版本不代表没用很多历史项目锁死了 node 版本你在新版本下跑 npm install 会报一串错误只有切回老版本才能正常启动。这类情况在用 Nuxt 做中间层、基于 vue pure admin 和 Node.js 连接 MySQL 的老项目中特别常见。如果现在有人给你一个 node-v13.9.0-win-x64.zip多半就是这种场景——要么是旧项目要求要么是某个教程指定了版本。像 14.21.x 这种偶数线版本、18.20.x 和 20.x 这种新 LTS 版本才是日常下载更推荐的选择。1.3 为什么有人偏爱 zip 而不是 msi两种格式的区别本质上是“安装方式”的区别格式安装方式优点缺点msi图形化向导自动写注册表并配置 PATH小白友好有卸载入口系统集成度高版本切换麻烦可能残留注册表项zip解压即用手动配置 PATH绿色可迁移多版本共存方便不污染系统需要手动处理环境变量我在开发机上更喜欢 zip。原因很实际用 msi 装的 node 会注册到系统装完想换版本还得去卸载来回折腾非常累。用 zip 版可以解压出 node-13、node-14、node-16 几个文件夹想用哪个版本就把哪个路径放到 PATH 最前面或者直接交给 nvm 管理切换成本极低。这套“手动部署”的思路放到 Linux 的 tar.xz 包和 macOS 的 tar.gz 包上也一样通用只是后缀名不同、没有 PATH 环境变量界面而已。2. 手动部署把 zip 包变成可用的 node 环境2.1 解压与目录规划拿到 node-v13.9.0-win-x64.zip第一步是解压。我建议把它放到一个固定、无中文、无空格的目录下比如 D:\dev\nodejs。尽量不要放在 C:\Program Files\nodejs 这种带空格的路径里虽然不是不能运行但在某些脚本、自动化工具和老旧的第三方工具里很容易因为路径解析出问题。解压之后目录里应该能看到 node.exe、npm.cmd、npx.cmd 等核心文件。此时可以打开命令行窗口切到解压目录输入 node -v 试试如果能够输出版本号说明文件本身没问题。注意不要直接双击 node.exe 来测试因为双击打开的是 REPL 交互界面看起来像黑屏加一个 提示符新手容易懵而且关掉窗口就什么痕迹都没了。注意真正要做的是把 node.exe 所在目录加入 PATH让终端在任何路径下都能直接找到 node 命令。这才是“安装”的关键一步。2.2 配置 PATH 环境变量Windows 上配置 PATH 的路径是此电脑 - 属性 - 高级系统设置 - 环境变量。这里我推荐修改用户变量里的 Path而不是系统变量。系统变量对所有用户生效权限要求更高容易误伤用户变量只对当前账户生效日常开发完全够用。操作步骤在用户变量中找到 Path双击进入编辑界面。点“新建”填入解压目录比如 D:\dev\nodejs。点“确定”保存然后关掉所有命令行窗口重新打开一个 cmd 或 PowerShell。验证方式很简单在任意目录下输入node -v如果显示 v13.9.0说明 node 本身已经生效。再输入npm -v如果也输出了版本号说明随包自带的 npm 也能正常调用了。2.3 环境变量配置的 3 个细节第一个细节Path 条目如果写得不对比如少了盘符、多了空格或者以反斜杠结尾一般不会立刻报错但某些工具拼接路径时会出现双斜杠。最好养成不写结尾反斜杠的习惯路径也尽量用纯英文。第二个细节如果电脑上同时装了 msi 版 node 和 zip 版 nodePATH 里可能存在多个 node 路径。系统会按 PATH 中的顺序从上到下查找第一个 node.exe所以想用哪个版本就把它的路径排在前面。很多人问“为什么 node -v 显示的不是我装的那个版本”八成就是这个原因。第三个细节不要为了图省事把 node.exe 直接拷贝到 C:\Windows\System32 目录。这个做法在某些老教程里出现过看似有效但系统更新或清理临时文件时 node 可能直接消失还会和其他工具冲突。正确做法永远是配置 PATH。3. npm 命令体系node 的“包管家”也要配置3.1 node 和 npm 到底是什么关系装完 node很多人直接就开始 npm install但完全不理解 node 和 npm 的分工。给个粗浅但好记的类比Node.js 是“运行时”负责把你的 JavaScript 代码真正跑起来类似汽车的发动机npm 是“包管理器”负责下载、安装、更新项目依赖的第三方模块类似汽车的加油站。npm 是随 node 一起发布的所以只要 node 装好了npm 一般也就有了。zip 版也一样解压目录里的 npm.cmd 就是。这里要特别提一下 Windows 的一个差异在命令行里执行 npm系统依赖的是 npm.cmd 这个批处理文件它和 node.exe 在同一个目录里所以 PATH 配置对了node 和 npm 两个命令都能用。此外还有一个 npx 命令它可以临时运行某个包而不全局安装适合那种“只用一次”的工具。3.2 全局目录与缓存目录重定向默认情况下npm 的全局包会装到 node 安装目录下的 node_modules 里。用 zip 版的人建议做一次重定向把全局包和缓存放到独立目录方便管理。我自己的配置是npm config set prefix D:\dev\nodejs\node_global npm config set cache D:\dev\nodejs\node_cache设置完以后全局安装的工具比如 nodemon、vue-cli、npm-run-all 等都会被装到 D:\dev\nodejs\node_global 下。这时候你还要把 D:\dev\nodejs\node_global 也加入 PATH否则在命令行里敲这些全局工具的名称时系统还是找不到。如果不做重定向会怎样实测最常见的结果就是 C 盘空间被 npm cache 慢慢占满同时全局包和 node 版本绑得太死——你要是哪天想切换 node 版本全局包就会残留在旧目录里形成混乱。所以这个配置建议在第一次用 npm 的时候就顺手做好。3.3 镜像源与下载提速npm 默认的官方源在海外服务器上国内访问速度确实比较慢。这不是玄学是网络链路问题。解决办法是换成国内的公共 npm 镜像源npm config set registry https://registry.npmmirror.com换完以后npm install 的速度会有质的提升。验证一下npm config get registry只要输出的是 npmmirror 的地址就说明配置成功了。这里有个经验镜像源存在同步延迟。如果你刚发布了一个新包立刻去 npm install 可能拉不到最新版过几分钟再试就好。遇到个别包在镜像源上缺失的极端情况也可以在命令后面临时指定官方源安装npm install 某个包 --registryhttps://registry.npmjs.org4. 版本管理从“死版本”到 nvm 切换4.1 为什么开发机不该只装一个 node这是我踩过最大的坑。早年我电脑上只装了一个 node版本跟着教程走装完就再没管过。直到某天拉下一个老项目npm install 报了一堆 OpenSSL 相关的错npm run dev 完全起不来再看另一个新项目依赖明确要求 node 版本必须大于等于 18。那一刻我彻底明白node 环境不应该是一个“装完就忘”的静态组件它应该跟随项目需求随时切换。不同项目的 node 版本要求差异是真实存在的老项目用 Vue 2 旧版 vue-clinode 10 或 12 跑得好好的升到 16 就开始报各种兼容错误Node-RED 这类工具对 node 版本有明确的上下限版本不对直接启动失败基于 vue pure admin Node.js MySQL 的全栈项目搭建时官方文档往往指定某个 LTS 版本Claude Code 这类较新的 AI 工具要求 node 18 以上老版本直接起不来。所有这些场景的共同答案就是用一个版本管理器来管理 node而不是每次手工下载 zip、反复改 PATH。4.2 nvm-windows 的安装与使用Windows 上最主流的 node 版本管理器是 nvm-windows。要注意它和 macOS 或 Linux 上的 nvm 不完全是一个东西语法略有差异但核心思路一样下载、安装、切换不同版本的 node。安装 nvm-windows 之前有一个关键步骤先卸载已经安装的 node并且把 PATH 里手写的 node 路径清掉。否则 nvm 管理的版本和你手动装的旧版本会打架出现“node -v 永远显示系统里另一个 node”的诡异问题。安装完成后常用命令就这几个nvm list # 查看已安装版本 nvm install 13.9.0 # 安装指定版本 nvm install 18.20.2 # 安装另一个版本 nvm use 13.9.0 # 切换当前使用的版本切换成功后node -v 会跟随当前版本变化。此时你会发现 npm 也随版本一起被隔离了——每个 node 版本有自己的一套 npm 和全局包目录这是 nvm-windows 的设计也是它能避免全局包版本混乱的原因。代价是你在这个版本下全局装的工具切到另一个版本就没了需要在新版本下重新装一次。这个特性刚开始有点反直觉但用久了会发现其实是种保护。4.3 老项目新项目并存的实际操作我现在的做法是在项目里建立一条简单的规范在项目根目录放一个 .nvmrc 文件内容就是项目要求的版本号比如 13.9.0 或 16.20.2每次进入项目先执行 nvm use 切换版本再执行 npm install把 node 版本信息写进 README团队其他人照着做。这样一来即使电脑里同时有 node 13、14、16、18 四个版本也不会混乱。我自己就是五个版本共存日常按项目切换基本没有因为版本问题再卡过壳。相比手改 PATH 的时代效率提升非常明显。5. 踩坑实录版本与环境的 5 个高频问题5.1 “node 不是内部或外部命令”这个报错出现的时机几乎都是刚配完环境变量、打开终端输入 node -v 的时候。原因一般有三个PATH 没配置成功或者配置之后没有重新打开终端PATH 里的路径写错了比如少了盘符或者多打了个空格系统里开着 Windows 商店版 Node.js 的“应用执行别名”PATH 里找不到 node.exe 时系统把命令转发给了应用商店弹出一堆无意义的提示。第三种情况很多人会忽略。解决方法是去“设置 - 应用 - 应用执行别名”把 node 相关项关掉。关掉之后node 命令就会老老实实走 PATH 查找。5.2 报错 internal/modules/cjs/loader 和 Cannot find module看到 node:internal/modules/cjs/loader 后面跟一大段路径最后是 Error: Cannot find module xxx不用慌。这说明 node 进程确实跑起来了只是找不到某个模块。最常见的三种原因项目目录里没跑过 npm install或者 install 中途中断node_modules 不完整全局工具找不到是因为全局路径没配置进 PATH或者 NODE_PATH 没指向全局 node_modulesnode_modules 被误删或者被嵌套进了子目录导致模块解析失败。处理思路先确认 npm install 是否完整执行过再检查 node_modules 目录是否存在最后重新安装依赖。如果怀疑本地缓存有问题可以执行npm cache clean --force这个命令会清掉所有缓存下一次 install 会慢一些但能解决一部分“临时文件损坏”型问题。5.3 ComfyUI、Node-RED 等工具报 node 错误很多桌面级工具和自动化工具底层依赖 Node.js。ComfyUI 报“节点在执行过程中发生错误”、Node-RED 启动失败、PHP 项目里调用 puppeteer 提示找不到 node这些都是同一类问题外部工具找不到 node 可执行文件或者找到的 node 版本不匹配。我的排查顺序是先在终端确认 node -v 和 npm -v 都输出了预期版本再查工具要求的 node 版本上下限比如 Node-RED 某些版本明确不支持太老的 node最后确认工具是用 npx 还是全局命令启动的npx 需要联网拉包网络不通时也会报“找不到模块”。还有一个容易被忽略的点ComfyUI 这类工具如果从整合包解压出来它内部可能自带一个 node 或者在配置里写死了 node 路径。此时系统里装了什么版本反而无关紧要要改的是工具自己的配置文件和启动脚本别一上来就卸载重装系统 node。JetBrains 系 IDE 的 AI Assistant 组件报 node 相关错误也同理先看它调用的是内置 node 还是系统 node。5.4 从 v12.22.12 升级到 v16.20.2 后项目起不来版本升级是老项目最容易出问题的节点。从 v12.22.12 升到 v16.20.2我总结下来最常见的三类问题依赖包兼容性一些老库没有及时更新对新版 node 的 API 或内部行为不兼容OpenSSL 相关报错node 17 之后 OpenSSL 3.0 默认开启导致 webpack 4 这类老工具直接挂掉报错信息里能看到 openssl 字样。解决办法是启动时加一个参数set NODE_OPTIONS--openssl-legacy-providermacOS 和 Linux 下则把 set 换成 export。语法兼容老代码用了新版本中已移除的 API或者反过来新版本要求的 module 导出方式在老版本里不支持。比如报错显示“the requested module node:util does not provide an export named XXX”多半就是版本和包之间的匹配出了问题。我的建议很直接升级 node 版本不要一步跨三个大版本。从 12 升 16 还好如果从 12 直接蹦到 20大概率会碰见一堆“意外惊喜”。项目没有硬性要求的话先用 nvm 切到 16 试试能跑就让它先跑着。5.5 关于旧版本 zip 包的最终建议如果你手上只有这个 node-v13.9.0-win-x64.zip优先用来跑老项目完全没问题。但如果是准备学习新知识、搭建新项目我建议还是用 nvm 装一个更新的 LTS 版本比如 18 或 20再装一个 13 或 14 用来兼容旧项目。这样既不会荒废手里已有的包也不会让新项目被旧版本卡住。最后说一个我自己的习惯所有 node 相关的东西都放在 D:\dev 下面node 压缩包解压到 D:\dev\nodejs全局包放在 D:\dev\nodejs\node_global缓存放在 D:\dev\nodejs\node_cache。每次重装系统之后只要重新装一个 nvm再从版本列表里逐个 nvm install十几分钟就能恢复全部开发环境。这个思路你可以直接拿去用省下大把“环境怎么又坏了”的时间。本文还有配套的精品资源点击获取