如果不是为了在HoRain云那台Windows云主机上搭Vue.js开发环境，我可能到现在都不会认真研究Windows下Node.js、npm和Vite之间那些说不清的破事。以前总觉得前端开发就是打开编辑器、敲命令、看页面，环境什么的不值得单独写一篇，直到我在一台全新的Windows Server上从零装环境，被各种报错折腾到凌晨两点，才发现这套流程里值得记下来的细节比想象中多得多。
这篇文章就写给我自己，也写给那些需要在Windows机器上搭建Vue.js开发环境的人。不管你是想在云主机上做远程开发、临时跑一个前端项目给客户演示，还是单纯想在Windows本地上把环境搞利索，这篇都能给你一套可以直接照着抄的完整流程。我会把版本选择、npm配置、脚手架选型、调试链路的坑全部摊开讲，包括怎么处理端口占用、命令闪退这类Windows特色问题。
1. 为什么非要在Windows云主机上折腾前端环境
先解决一个灵魂拷问：前端开发不是有台笔记本就能干吗，为什么要把环境装到云主机上？如果你从来没想过这个问题，说明你还没遇到下面这些场景。
1.1 云主机在前端工作流里的真实位置
很多人一想到云主机，脑子里全是后端接口、数据库、Nginx，很少把它跟前端开发扯上关系。但实际情况是，云主机就是一个远程的Windows电脑，它跟你本地电脑没有本质区别。你可以在上面装Node.js、拉代码、跑开发服务器，然后通过浏览器访问，甚至把Vite的dev server绑定到公网端口，让客户直接看效果。
我这次用的是HoRain云的Windows云主机，配置不高，2核4G，但跑Vue.js开发环境绰绰有余。前端开发服务器本身不重，真正吃内存的是Node进程和浏览器，4G内存跑Vite非常轻松。如果你要跑的是大型项目，比如几十个页面的后台管理系统，建议直接上4核8G，因为npm install和依赖编译阶段偶尔会吃满CPU和内存。
1.2 适合把环境装在Windows云机上的三类场景
我总结了三种典型场景，你可以对号入座。
第一种是远程协作开发。团队里有人用Mac有人用Windows，但项目某部分只能在特定环境下复现问题。这时候在云主机上搭一套标准Windows环境，谁连上去都能复现、都能调试，比每个人各自折腾本地环境省心得多。
第二种是临时演示和交付。你给客户做一个Vue.js原型页面，客户那边没有开发环境，你也不想把源码直接扔过去。最省事的办法就是把环境搭在Windows云主机上，把dev server跑起来，给客户一个链接，他打开浏览器就能看到效果。演示完了直接关掉，干净利落。
第三种是自动化构建和测试。很多前端项目需要统一的构建环境来做打包、跑测试，Windows云主机可以作为其中一台构建节点。尤其是一些依赖了Windows特有功能（比如某些原生模块）的项目，在Linux上还跑不起来，必须用Windows环境。
1.3 我的机器配置参考
在往下讲之前，先交代一下我这次实践的基线环境，方便你对照：
| 配置项 | 我的环境 |
|---|---|
| 操作系统 | Windows Server 2022（也可以用Win10/11） |
| CPU | 2核 |
| 内存 | 4GB |
| 磁盘 | 60GB SSD |
| 预装内容 | 无，从零开始 |
我需要特别说明一点：如果云主机是Windows Server版本，默认情况下很多桌面相关组件和开发相关的Visual C++运行库可能没有。后面安装Node.js如果报了缺少DLL或者运行库的错误，不用怀疑，先去补上对应的运行库再重试。这一条建议值回票价。
2. 装Node.js：版本、架构和管理器的三选一
这是整个搭建过程的第一步，也是最容易埋雷的一步。我见过太多人直接下载一个最新版Node.js，装完才发现项目跑不起来，然后又卸载、又装老版本，白白浪费一个小时。
2.1 版本怎么选：LTS是底线，但也要看脚手架要求
Node.js的版本策略是双轨制：偶数版本是LTS（长期支持），奇数版本是Current（当前版）。对于搭建Vue.js开发环境，我的建议只有一个字：稳。选LTS，千万别追新。
原因很简单：Vue.js生态里的工具链，包括Vite、Vue CLI、各种loader和插件，都会优先适配LTS版本。你用一个刚发布的Node 23或24，Vite可能跑得起来，但某个依赖的native模块编译不过去，到时候你排查半天，最后发现是Node版本太新，那个包还没跟上，你说冤不冤。
那具体选哪个LTS呢？以当前时间段来说，我倾向于Node 20.x或22.x。Vite 5/6/7对Node版本的要求有细致的对应关系，Vite 6要求Node 18.0或20.0以上，Vite 7要求Node 20.19+或22.12+。为了避免麻烦，直接上22.x LTS是最省心的选择，npm版本也会跟着来到10.x以上，足够用了。
2.2 一步步安装Node.js与npm
如果你不需要多版本切换，直接从官网下载Windows安装包（.msi）是最快的方式。这里有几个安装过程中特别容易被忽略的点：
- 安装目录不要有中文和空格。默认的
C:\Program Files\nodejs其实是有空格的，但这是Node官方默认路径，工具链都能处理，问题不大。真正要避开的是中文用户名目录，比如C:\Users\张三\AppData这种。如果你的Windows登录名是中文，装Node的全局包、缓存的时候大概率会踩到编码和路径坑，后面我会细说。 - 安装向导里有个"Add to PATH"选项，一定要勾上，这是让命令行能直接识别
node和npm命令的关键。 - 安装完成后，打开一个新的CMD或PowerShell窗口（注意，必须是新窗口，因为旧窗口不会刷新环境变量），输入以下命令验证：
node -v npm -v如果能看到版本号输出，说明安装成功。如果你用的是Windows Server，系统可能默认没有安装任何终端增强工具，直接用系统自带的PowerShell就行，不需要额外装Windows Terminal。当然你想装也完全可以，只是跟Vue环境本身没有关系。
2.3 用nvm-windows管理多版本，避免项目兼容性灾难
如果你同时维护多个项目，有的项目还在用Vue 2 + Vue CLI，有的已经切到Vue 3 + Vite，那强烈建议你在一开始就装nvm-windows，而不是直接装Node.js。
nvm-windows是Node Version Manager的Windows版，注意它跟Mac/Linux上的nvm不是同一个程序，用法略有区别。安装步骤很简单：
- 先去nvm-windows的GitHub releases页面下载
nvm-setup.exe。 - 安装时有两个路径要设置：nvm的安装目录和Node.js的软链接目录。我的经验是，nvm目录放
D:\nvm，Node目录放D:\nodejs，两个路径都不能包含中文和空格。如果你只有一个C盘，那就老老实实放C盘根目录，比如C:\nvm和C:\nodejs，不要再套一层Program Files。 - 装完之后，命令行输入
nvm version确认可用。 - 然后执行：
nvm install 22 nvm use 22这里有个Windows版特有的大坑：如果之前已经装过Node.js的MSI版本，nvm-windows会提示你“检测到已安装的node，请先卸载”，因为nvm是通过符号链接来控制当前Node版本的，和MSI安装方式有冲突。所以如果你打算用nvm，那就先别用安装包装Node。反过来，如果已经装好了，要么先卸载再用nvm，要么干脆别用nvm，直接用固定版本。
nvm装好后，每次切换版本只需要：
nvm use 22不需要手动改PATH，不需要重开终端，确实能省掉很多麻烦。
3. npm配置：镜像源、缓存目录和全局包路径
Node装好只是第一步，真正让人血压升高的是npm。在Windows下，npm默认配置有三大问题：下载慢、全局包路径权限折腾、还有路径长度限制。这节我把它们一个个拆开讲。
3.1 换镜像源之前，先搞清楚npm到底卡在哪
很多人一遇到npm install慢就想着换镜像，但“慢”这个字描述得太笼统了。我实测下来，npm卡住的原因通常有三个维度：
- 网络连接问题：默认源是官方registry，某些网络环境下连接不稳定，表现为长时间停留在
node install那一步不报错也不继续。 - 并发下载问题：npm默认会以较高的并发度拉取包，如果网络带宽不足或者路由不稳定，会出现部分包下载超时，然后反复重试。
- 磁盘IO问题：在Windows云主机上，如果系统盘本身性能一般，npm解压大量小文件时会非常慢，这跟网络没关系，纯粹是磁盘碎片化或IO瓶颈。
判断是哪种问题有个简单方法：看npm install输出日志。如果卡在某个包名上很久，然后用红色字体报ETIMEDOUT或ECONNRESET，基本是网络问题；如果包包下完了但卡在node_modules创建阶段缓慢推进，那是磁盘或者解压问题，换个镜像也救不了你。
解决办法在Windows下最立竿见影的方案是：把npm的registry切到国内镜像。你不用管它是谁提供的，反正配置方法都一样。在命令行执行：
npm config set registry https://registry.npmmirror.com设置完可以用以下命令验证：
npm config get registry看到镜像地址就说明生效了。这一步做完，npm install的速度通常会有明显提升，尤其在拉取一些体积比较大的包时，效果肉眼可见。
3.2 修改npm全局配置的正确姿势
除了换镜像，我强烈建议你顺手把npm的缓存目录和全局包安装路径改一下。原因很现实：Windows的C盘空间容易紧张，而node_modules占空间的能力你是知道的。在云主机上，如果C盘只有60GB，装几个全局工具、跑几次npm install，C盘就见红了。
用命令行配置是最干净的方式，不用手动去编辑.npmrc文件，敲几个命令就行：
npm config set cache "D:\npm-cache" npm config set prefix "D:\npm-global"这时候有一个关键动作千万别漏掉：修改完prefix之后，原来C:\Users\你的用户名\AppData\Roaming\npm这个路径就不生效了，但PATH环境变量里还指着旧路径。你得手动把新路径D:\npm-global加到系统PATH里，否则后面全局安装的命令（比如vue、vite）会提示找不到。
具体操作是：右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量，在“系统变量”里找到Path，编辑，新建一行填入D:\npm-global，确定保存。改完以后务必重新开一个终端窗口。
这里再提醒一句：如果你的Windows登录用户名是中文，比如C:\Users\测试，npm默认的全局目录就在这条中文路径下。某些老旧的npm包在处理中文路径时会出现乱码、找不到模块的问题。遇到这个情况，除了改prefix，还要改一个临时目录环境变量TEMP和TMP到不带中文的路径，比如D:\tmp，能省掉大量诡异报错。
3.3 解决“文件被占用”“路径过长”的Windows专属问题
Windows上跑npm install，最常见的两个报错一个是EPERM: operation not permitted，另一个是ENAMETOOLONG。
EPERM的意思是文件被占用，最常见场景是：你正在跑npm run dev，然后没停掉进程就执行npm install去装新包，结果npm想覆盖某个正在被Node进程读取的文件，Windows就会拒绝操作。解决办法很简单：先停掉开发服务器，再执行install。如果停了还报错，通常是某个Node进程没退干净，把它找出来手动结束掉，具体命令我在第6节会讲。
ENAMETOOLONG是Windows的经典毛病，文件路径超过260个字符就会被系统拒绝。npm安装依赖时会生成很深的文件结构，很容易触发这个限制。解决办法有两个：
- 在注册表里启用长路径支持。用Win+R打开运行，输入
regedit，定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，找到LongPathsEnabled，把值从0改成1，重启系统生效。 - 手动配置npm使用扁平化的依赖安装方式？其实npm本身不允许关闭深路径。最有效的还是启用长路径，或者把项目放浅层目录，比如直接放
D:\project\my-app，而别放C:\Users\某某\Documents\Work\Projects\2025\xxx\my-app这种。
我个人的组合技是：启用长路径支持 + 项目目录尽量放浅层，这两件事做完，基本再没见过ENAMETOOLONG。
4. 脚手架选型：Vite和Vue CLI到底选谁
环境基础打好了，接下来就是创建项目。这一步的新手困惑通常集中在：用Vite还是Vue CLI？我带过不少项目，也见过老项目继续用Vue CLI的，这里聊聊我的看法，以及Windows下的实际操作。
4.1 两个脚手架的现状
Vue CLI是Vue官方早期推的脚手架，基于Webpack，功能全、插件生态成熟，但一个显著缺点是慢。在Windows云主机上，Webpack冷启动和热更新都要吃不少资源，跑个中型项目动辄几十秒，体验很一般。
Vite是Vue团队现在主推的工具，基于ESBuild和Rollup，开发服务器启动速度极快，热更新也是毫秒级的。它最大的优势在开发体验，对Windows的亲和度也更好。现在新开项目，我基本无脑选Vite。如果你维护的是老项目，Vue CLI也可以用，但千万别再去vue create新起项目，Vite才是当下的正确选择。
还有一个细节：Vite官方脚手架create-vite在2025年的版本创建Vue项目时，Node版本要求已经不低，所以第2节我让你装Node 20.19+或22.12+是对的，别再纠结老版本了。
4.2 用Vite搭建第一个Vue项目的完整过程
装好环境后，打开PowerShell或CMD，找一个干净的目录（我的习惯是D:\projects）执行：
npm create vite@latest my-vue-app -- --template vue解释一下这条命令的思路。npm create vite@latest会去下载最新版的create-vite脚手架，my-vue-app是项目名，-- --template vue表示使用Vue模板。如果你需要TypeScript支持，把最后改成--template vue-ts，然后按提示选择即可。
执行过程中，脚手架会问你是否安装依赖并启动项目。我一般选“否”，等创建完成后再手动进目录执行npm install。原因是把安装依赖和启动服务器的过程分开，方便观察每一步执行情况，报错了也不会一团乱麻。
进目录、装依赖、启动开发服务器：
cd my-vue-app npm install npm run dev第一次跑npm install可能需要几分钟，这取决于网络和机器性能，属于正常现象。启动成功后会看到类似这样的输出：
VITE v6.0.x ready in 800 ms ➜ Local: http://localhost:5173/看到Local这个地址，说明环境已经通了，Windows下最基础的Vue.js开发环境到这里就算搭完了。你用浏览器访问本机的http://localhost:5173，应该能看到Vue官方的示例页面。
4.3 项目创建后的目录结构与基础配置解读
Vite创建Vue项目的目录结构非常精简，我挑几个必须搞懂的讲一下：
index.html：整个应用的HTML入口，Vite把它当作构建入口，而非像Webpack那样从JS入口推导HTML。src/main.js：Vue应用的启动入口，负责createApp并挂载根组件。src/App.vue：根组件，里面可以看到Vue单文件组件的基本结构——template、script、style三段。vite.config.js：Vite的核心配置文件，端口号、代理、构建选项都在这改。package.json：项目元数据和脚本命令。
在Windows下重点先说vite.config.js，因为你要改的第一个配置大概率在这里——端口。默认是5173，如果你同时跑多个项目，端口会不够用。修改端口：
// vite.config.js export default defineConfig({ server: { port: 5173, strictPort: true } })strictPort设成true后，如果端口被占用，Vite不会自动换端口，而是直接报错。这个设计在开发阶段是个好事，因为它能让你立刻发现“是不是有旧进程没杀掉”的问题，而不是默默换端口然后一脸懵。
4.4 Windows下Vite特有的“监听文件”问题
在Windows上跑Vite，偶尔会遇到修改代码后热更新不生效，必须手动刷新页面才看到变化的情况。这个问题通常有两个来源：
一是Windows云主机上如果装了某些同步盘或安全软件，它们会锁定文件句柄或者拦截文件变化事件，Vite的chokidar监听器就收不到修改通知。解决方案是在vite.config.js里调整监听选项：
server: { watch: { usePolling: true, interval: 100 } }usePolling会让Vite轮询文件变更而不是依赖操作系统的事件通知，虽然多消耗一点CPU，但能绕开很多Windows文件系统监听的老毛病。
二是项目目录在某个被同步工具托管的位置，比如OneDrive同步文件夹。Node.js和各种watcher在同步目录下经常出现文件事件风暴或漏事件，最好的办法是把项目目录挪到同步文件夹之外。
5. 开发调试链路：devtools、代理、局域网访问和热更新
环境跑起来之后，接下来的体验优化才是真正拉开差距的地方。很多人在本地跑得好好的，一上Windows云主机就懵了：浏览器里看不到Vue组件、接口跨域、手机访问不了页面。这节就是把调试链路打通。
5.1 安装Vue.js devtools插件
调试Vue应用，没有Vue.js devtools相当于睁开眼睛摸黑。如果你是Edge用户，直接在扩展商店搜“Vue.js devtools”点安装就行，这里不废话。如果你用的Chrome，去Chrome Web Store安装。
装完之后有个坑：你打开页面看到的可能不是Vue组件面板，而是空白。这是因为devtools默认检测页面里的“Vue关键标记”，如果没检测到，它会认为当前页面没有用Vue。
解决办法：那个版本太旧了，或者当前页面没跑起来。真实经历告诉你，如果你是用file://协议打开打包后的HTML，devtools不工作，因为它需要开发模式的上下文。正确的验证方式是：把Vite dev server跑起来，用http://localhost:5173访问页面，再打开devtools，切到Vue标签才能看到组件树。另外，新版devtools有“允许访问文件URL”的开关，如果你确实需要调试打包产物，在扩展详情里打开这个权限，再重新加载页面。
5.2 接口代理配置：开发环境跨域问题
开发Vue项目时，前端请求后端接口必然遇到跨域。后端可能部署在另一台云主机上，也可能跟你不在一个内网，前端如果直接发请求，浏览器会拦截响应。解决方式有几种，最常用的是在Vite里配代理。
举个例子，你的项目里写请求路径是/api/login，实际后端接口完整地址是http://192.168.1.100:8080/login，开发环境就能在vite.config.js里这样配：
export default defineConfig({ server: { proxy: { '/api': { target: 'http://192.168.1.100:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } })配置逻辑是：所有以/api开头的请求，Vite开发服务器都会转发到target地址，rewrite把/api前缀去掉，这样后端收到的就是/login。
changeOrigin一定要设成true，这样后端收到的请求头Host是目标服务器的域名，而非你的开发服务器地址，很多后端鉴权依赖Host校验，不设这个字段就会莫名其妙的401。
这个配置改完需要重启dev server才能生效。Vite配置文件是vite.config.js，改动后它会自动重启吗？默认不会，建议手动停掉再npm run dev一次。
5.3 让手机和同事也能访问：开启局域网访问与防火墙放行
在云主机上跑Vue开发环境，几乎必然面临一个需求：让不在本机的人也能访问到页面。Vite默认只监听localhost，外部设备访问不到。解决方式是加一行配置：
server: { host: true }host: true会让Vite监听所有网卡地址，相当于把开发服务器暴露到局域网。提示一下，这在公共云主机上等于把开发端口对外开放，有安全隐患，但作为演示用途是常规操作。你需要在启动输出里找到Network地址，比如http://192.168.1.20:5173，把这个地址发给同事或客户就能访问。
不过现实总是打脸：设置了host: true，别人还是打不开。十有八九是Windows防火墙拦住了。Windows Server默认对公网入站连接管得很严，你需要在防火墙放行端口。用管理员身份打开PowerShell执行：
netsh advfirewall firewall add rule name="ViteDevServer" dir=in action=allow protocol=TCP localport=5173这条命令的意思是新增一条入站规则，允许TCP协议的5173端口访问。执行完再让同事刷新一次，一般就通了。
如果你用的云主机还带独立的安全组控制（大部分云厂商都有），光改Windows防火墙不够，还得去云控制台的安全组规则里放行5173端口。这个步骤特别容易被忽略，我在云主机上测试时，第一次就是改了防火墙但没改安全组，折腾了一下午才发现问题。
5.4 热更新失效和页面白屏的临时解法
开发过程中不可避免会遇到页面白屏，尤其是Windows云主机上，磁盘和内存都比较紧张时更容易触发。我的处理思路是按顺序排查：
- 先看终端有没有报错。终端里如果有红色错误信息，基本是编译错误，代码层面的问题，按错误堆栈去修。
- 如果终端正常但页面白屏，按F12打开浏览器控制台，看有没有网络请求失败或JS报错。
- 如果控制台也没有明显报错，试试强制刷新（Ctrl+F5），清掉缓存再看。
- 还是不行，就停掉dev server，删掉
node_modules和package-lock.json，重新npm install再启动。
最后这招看起来很笨，但简单有效。Windows环境下node_modules被破坏的概率比Linux高不少，比如突然蓝屏、磁盘满、杀毒软件扫描过程中删了文件，都可能导致依赖残缺。重装一次依赖，成本比排查半天低多了。
6. 高频报错排查手记：端口占用、闪退、权限弹窗
最后一节是全篇的精华所在，全是我在这些年Windows开发环境搭建和实际使用中踩过的坑。我把它们按“从现象到解决”的方式写下来，你不用踩一遍也能直接翻到对应场景。
6.1 端口占用：确认、杀掉进程、再启动
场景描述：启动Vite时报错，提示Port 5173 is already in use，或者更笼统的EADDRINUSE。
这是Windows下最高频的报错之一。原因很可能是你之前跑过dev server没停干净，或者另一个项目占用了相同端口。网上很多人让你改端口号逃避问题，但我建议先把进程找出来杀掉，免得后面一堆后患。
用管理员身份打开PowerShell，先查谁占用了5173端口：
netstat -ano | findstr :5173输出的最后一列是PID（进程ID），比如拿到12345，再用下面命令把这个进程结束掉：
taskkill /PID 12345 /F如果这个PID对应的进程是node.exe而你又确认不是其他项目在跑，那就放心杀。如果你不知道PID对应什么进程，可以先执行：
tasklist /FI "PID eq 12345"看下进程名，确认后再杀。杀完重新npm run dev，端口就干净了。
顺手提一句：我不建议一遇到端口冲突就改端口，那是治标不治本。每次换端口，你还要同步改代理配置、前端请求地址、防火墙规则，麻烦得很，不如花10秒把旧进程杀干净。
6.2 npm/node命令闪退的几种原因
场景描述：在CMD或PowerShell里输入node -v或者npm -v，窗口闪了一下就没了，或者显示几行乱码后立刻退出。
这类问题分三种情况：
第一种是命令本身以cmd脚本形式存在，双击.cmd文件时窗口一闪而过是正常现象，因为你没有暂停命令。但如果是你手动输入的node -v也闪退，那就不正常了。
第二种是PATH路径有问题。Windows搜索命令时按环境变量PATH里的顺序去找，如果PATH里某个路径不存在或指向了错误的Node安装目录，系统会提示“不是内部或外部命令”。解决方法是打开环境变量编辑器，把Path里跟Node.js相关的路径捋一遍。也顺便检查一下系统Path里有没有非法的空条目，把它们删掉。
第三种更坑——杀毒软件或安全策略拦截了node.exe。某些云主机默认开启了比较激进的安全策略，会把node.exe当作可疑进程，阻止它加载执行。表现就是双击node.exe没反应，或者命令行执行命令时一闪而过。这时候需要去Windows安全中心查看隔离记录，把node.exe和npm相关脚本加入信任区。我还遇到过系统管理员策略限制了PowerShell执行脚本，报错信息里会有running scripts is disabled on this system，解决方式是管理员身份执行：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这个设置的含义是允许本地脚本运行，但来自远程的脚本必须有签名，兼顾安全性和开发需要。
6.3 Windows的安全日志和事件查看器：最后的排查底牌
如果上面的方法都排查过了，问题依然存在，那就是非常规问题。这时候别瞎试，Windows自己有一本账，那就是事件查看器。
Win+X打开快捷菜单，选“事件查看器”，然后看“Windows日志 -> 应用程序”。所有程序异常退出的记录都会留在这里。比如Node.js闪退，你可以在日志里找到对应的错误事件，里面通常有具体的模块路径和错误代码。
安全日志也值得扫一眼，尤其当你怀疑某个进程被系统拦截时。Windows安全中心会在安全日志里记录进程创建、文件删除等操作。有一次我在云主机上遇到一个打不开npm命令的问题，查了一圈，最后在安全日志里发现是安全软件把npm脚本当成了可疑文件，自动隔离了。这类问题不看日志根本猜不到。
6.4 云主机上装环境时最容易忽略的系统组件
最后补充一个Windows Server特有的坑。Windows Server和普通Windows桌面版在预装组件上差异很大，开发环境经常缺东西。最典型的是缺少VC++运行库和.NET Framework的相关功能。
如果你在安装Node.js时提示缺少VCRUNTIME140.dll，或者npm install的时候某个依赖编译报错，别急着怀疑代码。先用系统自带的“添加角色和功能”向导，把“.NET Framework 3.5”和“桌面体验”装一下。装完之后很多神秘报错会自己消失。这个步骤在云主机上尤其重要，因为桌面版Windows通常已经自带，而Server版默认不装。
还有一点，Windows Server默认的IE增强安全配置是开着的，这会屏蔽很多内部网站和扩展的下载页面。搭建环境过程中如果需要下载工具，建议把“IE增强的安全配置”临时关掉，或者直接用Chrome/Edge浏览器。IE模式下访问某些下载链接会被强制拦截，很影响效率。
写在最后：我实际折腾完的几点体会
这套环境我前前后后搭过不下十次，最后一次在HoRain云上从空白系统开始，用上面这套流程大概花了不到四十分钟，其中大部分时间烧在npm install和等待各种安装程序上。如果中间不走弯路，二十分钟就能跑起来。
一个我每次都要反复叮嘱自己的习惯是：不要贪新。Node.js、Vite、Vue CLI这些工具，出新版本的速度快到你追不上，追新版本的结果往往是你的某个老依赖不兼容，然后陷入无底洞。老老实实跟着LTS和稳定版走，开发和调试省下的时间远远超过追新带来的快感。
还有一个非常实用的小技巧是：在Windows上跑Vue项目，尽量把终端窗口开着不要关。很多人看到cmd窗口黑乎乎的就烦，关掉之后又找不到日志，出了问题无从下手。我一般会开两个窗口，一个跑dev server，一个专门敲命令行操作。这样报错信息随时能看到，排查起来心里有底。
这套环境搭建的完整链路，从Node.js到npm再到Vite和调试工具，每一步都有Windows特有的坑，但也都有对应的解法。希望你踩坑的时候能想起这篇文章，少走几步弯路。
