Win10+IDEA从零跑通Vue：Node、npm、联调与打包部署

现在很多做 Java 后端的同学，第一次接触前端就是被安排去改一个 Vue 页面，而写代码的窗口还是那个熟悉的 IDEA。问题在于，IDEA 默认是个 Java IDE，它对 Node 环境、npm 脚本、Vue 单文件组件的支持并不是装完就自动到位，尤其是 Windows 10 这套系统，路径空格、权限、缓存目录、命令行环境变量这几处特别容易踩坑。这篇内容就是把我自己在 Win10 + IDEA 这套组合里从零跑通 Vue 的完整过程拆开讲清楚，覆盖 Node 环境搭建、IDEA 里创建和导入 Vue 项目、插件与运行配置、前后端分离联调、打包部署以及出错后的排查思路。不管你是完全没碰过前端的后端开发，还是刚学 Vue 想找个顺手的编辑器，看完都能自己动手把环境搭起来，并且知道每一步为什么这么做。

1. 环境准备：Node、npm 与 IDEA 版本怎么选

1.1 Node.js 装哪个版本，为什么建议用 nvm 管起来

Vue 项目运行在 Node.js 之上，新版本的脚手架工具基本就是围绕 Node 生态构建的。选版本这件事，我的建议是别追最新，也别用太老的。Vue 3 + Vite 这套组合，Node 16 已经偏老，Node 18 和 Node 20 是当前最稳的两个选择，都属于长期维护版本，绝大多数依赖包都验证过。Node 22 也能跑，但个别老项目里的 node-sass 之类的原生模块可能没有预编译包，装的时候会现场编译，Windows 上还要装 Visual Studio Build Tools，非常折腾，能避就避。

更关键的一点：不要直接从官网下载 msi 装一个全局 Node 就完事。理由很实际，你手上大概率不止一个项目，老项目锁在 Node 16，新项目想用 Node 20，全局只有一个版本就意味着每次切换项目都要卸载重装，这种体验很难受。所以我的做法是用 nvm-windows 来管多版本。

安装 nvm-windows 有几个细节值得强调。第一，安装路径别带空格和中文，默认是C:\Users\你的用户名\AppData\Roaming\nvm，里面的用户名如果是中文，建议改到C:\nvm和C:\nodejs这种纯英文路径，很多命令行工具对中文路径的处理一直不太靠谱。第二，如果你电脑上已经装过官方 Node，必须先卸载干净，否则 nvm 接管不了符号链接。第三，nvm 的 use 命令需要管理员权限，因为它要改C:\nodejs这个软链接，普通命令行窗口执行会静默失败但看起来像成功，这个坑很隐蔽。

装完之后在 PowerShell 里验证一遍：

nvm version nvm list available nvm install 20.18.0 nvm use 20.18.0 node -v npm -v

node -v输出v20.18.0，npm -v输出10.x之类的版本号，环境就算通了。如果node -v报找不到命令，先关掉当前窗口重开一个，因为环境变量是安装时写入的，老窗口读不到新值。

注意：nvm use之后node -v输出的版本和你刚设的不一致，八成是原来的 Node 安装目录还在 PATH 里并且排在前面，去系统环境变量里把它移除。

1.2 IDEA 用哪个版本，社区版到底行不行

JetBrains 的 IDEA 分社区版和旗舰版两条线，这块的选择直接决定你在 Vue 开发上的体验上限。旗舰版内置了对 JavaScript、TypeScript、Vue、React 这些前端技术的完整支持，装完打开.vue文件就能有语法高亮、组件跳转、模板里表达式补全、路由跳转提示，这些功能是实打实提升效率的。社区版从 2023.1 开始也逐步补上了部分 Web 开发能力，日常写写简单页面没问题，但在模板语法解析、组件引用识别、路径跳转这些地方明显弱一档，遇到大一点的项目经常出现"能打开但跳不过去"的情况。

我的实际建议是这样：如果公司给配了正规授权，直接上旗舰版，省下来的时间远超授权成本。如果只是个人学习、写点小工具，社区版完全能跑通整个流程，搭配几个插件也能凑出七八成的体验。至于网上流传的那些非正规获取方式，我不推荐也不展开，版本不稳定、插件市场连不上、更新被卡，最后浪费的时间比省下的钱多得多，而且用起来心里也不踏实。

IDEA 版本本身建议选 2023.3 之后的，Node.js 和 npm 的支持更完善，对 Vite 项目的识别也准。下载安装时勾选"创建桌面快捷方式"和"关联 .js 文件"就够了，其他可以默认。安装路径同样避开中文和空格。

1.3 目录规划和缓存位置，别让 C 盘先炸

这一步很多人跳过，但上班半年后就会后悔。npm 的全局包缓存默认在C:\Users\你的用户名\AppData\Local\npm-cache，一个中型前端项目装完后 node_modules 动辄三五百兆，缓存目录堆到十几 G 是常事。我的做法是把缓存和全局包目录挪到 D 盘：

npm config set prefix "D:\dev\npm-global" npm config set cache "D:\dev\npm-cache" npm config get registry

同时把D:\dev\npm-global加到系统 PATH 里，这样全局装的命令行工具才能被找到。项目本身也建议统一放在D:\workspace\这种短路径下，路径层级太深加上 Windows 260 字符的路径长度限制，某些依赖解压时会直接报错，报错信息还特别不直观，只说文件写入失败，让人完全想不到是路径长度问题。

还有一点，node_modules 目录建议加到杀毒软件的排除列表。Windows Defender 实时扫描会逐个检查这些几万个小文件，导致npm install从 40 秒变成 5 分钟，npm run dev启动也明显变慢。这个操作不涉及任何安全风险，纯粹是性能考虑。

2. IDEA 里创建和导入 Vue 项目的完整流程

2.1 用脚手架生成项目，别在 IDEA 里手动建文件

一个常见的误区是打开 IDEA 新建一个空项目，然后自己建 index.html、main.js 一个个往里填。这样做出来的东西没有构建配置，跑不起来，而且你也不清楚哪些文件是必需的。正确做法是用官方脚手架在命令行生成标准项目骨架，再用 IDEA 打开。

目前 Vue 官方推荐两条路：Vite 和 Vue CLI。新项目一律用 Vite，冷启动基本在秒级，热更新几乎是即时的；Vue CLI 基于 webpack，启动动辄十几秒，只适合维护老项目。在命令行里执行：

cd /d D:\workspace npm create vite@latest vue-demo -- --template vue cd vue-demo npm install npm run dev

第一条命令里的--template vue指定用 JavaScript 版本的 Vue 模板，如果你要用 TypeScript，换成--template vue-ts。注意那个额外的--不能省，它的作用是告诉 npm 后面这些参数是传给 create-vite 而不是 npm 自己的，省掉会直接把模板参数吞掉，最后生成一个交互式提问，白白浪费一轮。

npm install完成后npm run dev，终端会打印类似Local: http://localhost:5173/的地址，浏览器打开能看到 Vue 的示例页面，说明骨架是好的。这个顺序很重要：先在命令行确认项目本身能跑，再去 IDEA 里配环境。如果直接跳到 IDEA，一旦页面打不开，你分不清是项目问题还是 IDE 配置问题，排查会绕很多弯路。

2.2 在 IDEA 中打开项目，让它正确识别 Node 环境

打开方式选File → Open，注意选的是包含package.json的那一级目录，不是它的父目录，也不是 src 目录。选错层级最典型的症状是 IDEA 右下角弹不出"Run npm install"，左侧项目树里package.json图标也是普通文本文件的样子，不显示 npm 脚本的运行三角。

打开后需要手动确认一次 Node 解释器，路径在Settings → Languages & Frameworks → Node.js。这里的Node interpreter选到 nvm 生成的软链接，也就是C:\nodejs\node.exe；Package manager选 npm，IDEA 一般能自动填上。如果这里显示的是<No interpreter>，那么后面所有 npm 相关的功能都是灰色的，跑不起来。

再回到package.json文件，右键能看到Show npm Scripts，点击之后左下角会多出一个 npm 工具窗口，dev、build、preview这几个脚本都在里面，双击就能运行。这个面板比每次切到终端敲命令方便得多，尤其是在同时开好几个项目的时候，不用来回切窗口。

顺手把另外两件事做了：一是Settings → Editor → File Encodings里，把全局、项目、属性文件三处编码统一设成 UTF-8 并勾选 BOM 不写入，避免中文注释在某些场景下变成乱码；二是检查Settings → Editor → File Types里.vue后缀是否被识别，正常情况下旗舰版自带识别，社区版需要靠插件。

2.3 依赖安装那点事：镜像源、锁文件与 npm ci

国内网络环境下直接npm install经常会卡在某个包上转圈，这时候把 registry 换成国内镜像源会顺畅很多：

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

改完之后npm install速度通常能从几分钟降到几十秒。如果项目里有公司内部的私有包，记得在后面按需切换回私有源，或者用.npmrc文件按项目级别配置，避免全局设置影响其他项目。

依赖管理上还有两个习惯值得养成。第一个是锁文件一定要提交到 Git，package-lock.json记录的是精确版本树，丢掉它之后不同人装出来的依赖版本可能不一致，就会出现"我这能跑你那报错"的玄学问题。第二个是 CI 环境或者部署环境用npm ci代替npm install，前者严格按锁文件安装，不会自动升级任何东西，速度快且结果可复现。

npm ci --registry=https://registry.npmmirror.com

npm install报错的时候，先看报错最后几行，通常真正的原因在最下面。常见的三类：一是网络超时，重试一次往往就好了；二是权限问题，提示 EPERM，多半是杀毒软件锁了文件或者没用管理员权限；三是 Node 版本不匹配，某个包在engines字段里声明了最低版本要求，这种情况按前面说的用 nvm 切版本。

2.4 读懂 package.json 和项目骨架，别把它当黑盒

把项目跑起来只是第一步，能看懂目录结构才算真正上手。一个 Vite + Vue 3 项目，核心东西就那么几样。

package.json里的scripts是你每天要用的入口：dev启动开发服务器，带热更新；build打包生产资源，产物默认落在dist；preview本地预览打包结果，这个命令很多人不知道，但它能在部署前快速验证打包产物有没有问题，非常有用。dependencies和devDependencies的区别也要清楚，只在前端代码里 import 的运行时库放前者，构建工具、代码检查工具放后者，放错了会导致生产构建把开发工具也打进去，包体积白白变大。

vite.config.js是构建配置的中心，端口、转发规则、别名、打包输出目录都在这里改。index.html是入口页面，Vite 从这个文件开始解析整个依赖图，所以它必须放在项目根目录，这点和 webpack 时代的习惯不一样。src下面，main.js负责挂载根组件，App.vue是根组件，components放公共组件，router放路由配置，store或stores放状态管理（Pinia 的约定是复数形式）。

提示：.env、.env.development、.env.production这三个文件用来区分环境变量，变量名必须以VITE_开头才能在代码里通过import.meta.env读到，没加前缀的读出来是 undefined，这个坑几乎每个人都踩过一次。

3. 让 IDEA 真正好用：插件、运行配置与调试

3.1 必装插件清单，以及每个插件解决什么问题

IDEA 装完只是毛坯房，插件是把体验拉到及格线的关键。下面这几个是我装了之后就没卸过的。

安装路径在Settings → Plugins → Marketplace，搜名字装完重启即可。这里提醒一句，插件不是越多越好，每个插件都会占用启动时间和内存，我见过有人装了四五十个插件，IDEA 冷启动要两分钟。按需装，用不上就卸载。

关于 Vue.js 插件有个容易被忽略的点：如果你的.vue文件里<template>部分显示为纯灰色文本、没有语法高亮，八成是插件没生效或者文件被识别成了纯文本。可以在Settings → Editor → File Types里检查.vue是否被关联到 Vue 模板，也可以在右下角状态栏点文件类型手动切换。

3.2 运行配置怎么建，为什么建议用 npm 配置而不是终端

虽然直接在终端敲npm run dev也能跑，但用 IDEA 的 Run Configuration 有几个实际好处：可以一键启动、可以把环境变量写进配置、可以看结构化的输出日志、可以随时点停止按钮把整棵进程树杀掉。最后一个尤其重要，Windows 上终端里 Ctrl+C 有时杀不干净子进程，端口一直被占用，下次启动就报Port 5173 is in use。

创建方式是点右上角的Add Configuration → npm，然后填几个关键项。package.json选项目根目录那个文件，Command选run，Scripts填dev，Node interpreter选前面配好的本地 Node。如果想同时跑后端和前端，再建一个 Spring Boot 的配置，两个配置可以分别启动，也可以放一个 Compound 里一键全起。

打包配置同理，把Scripts换成build就行。加一个preview配置放在旁边，打完包点一下就能看到实际产物效果，省得每次还要开终端。

// 参考：vite.config.js 里常见的开发服务器设置 export default defineConfig({ plugins: [vue()], server: { port: 5173, open: true, host: '0.0.0.0' }, resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)) } } })

host: '0.0.0.0'这一项在需要手机连本地服务调试移动端页面时会用到，通过局域网 IP 访问，前提是 Windows 防火墙放行了该端口。第一次访问弹防火墙提示时选"允许专用网络"即可。

3.3 调试：断点打在哪，怎么看变量

Vue 项目的调试分两层，理解这一点能省掉很多困惑。一层是浏览器里的代码，一层是 Node 侧的构建工具。Vite 的开发模式是把源码以 ES Module 的形式直接给浏览器，浏览器 DevTools 里看到的就是接近源码的代码，断点直接打就行，配合 Source Map 基本能一一对应。所以日常 90% 的调试需求，浏览器 F12 就够了，不需要额外配置。

IDEA 里能调试的是 Node 侧，比如你想看某个自定义构建插件在做什么、某个 npm 脚本执行到哪一步，可以用Attach to Node.js/Chrome类型的配置，或者创建一个 JavaScript Debug 配置指向http://localhost:5173，这样在 IDEA 里也能打断点。这个能力用得不多，但在排查构建期问题时很好使。

几条实战中总结的调试习惯。第一，console.log别只打值，把标记一起打出来，比如console.log('userList', list)，控制台一堆输出的时候能快速定位。第二，Vue 3 的响应式数据在控制台里看的是 Proxy 包装后的对象，想看原始值可以用toRaw()，或者直接看 DevTools 里的 Vue 面板，那个面板能直接看到组件的 props、data、setup 状态，比在控制台里翻对象直观得多。第三，网络请求问题优先看 Network 面板的请求头和响应体，比在代码里加日志快。

3.4 效率技巧：几个我每天都在用的操作

Alt + Enter是 IDEA 里最值钱的快捷键，代码有问题时它会给出修复建议，缺 import 能一键补上，变量没用能一键删掉。前端项目里组件引入、路径提示基本靠它。

Ctrl + Alt + L格式化当前文件，配合 Prettier 使用。建议在Settings → Tools → Actions on Save里勾上Run Prettier on save，从此不用手动格式化，保存即规范。

Ctrl + B跳转到定义，在.vue文件的模板里点组件名能直接跳到组件文件，这个功能在旗舰版里体验非常顺，社区版经常跳不过去。

Ctrl + Shift + F全局搜索，Ctrl + Shift + R全局替换，重构的时候注意替换范围，前端项目里字符串匹配很容易误伤 node_modules，记得在搜索框里排除掉该目录。

Shift + F6重命名，改组件文件名、变量名时会自动更新所有引用，比手动改安全得多。不过改.vue文件名时注意一下 import 路径里的大小写，Windows 文件系统不区分大小写，但 Linux 服务器区分，本地跑得好好的代码部署上去报模块找不到，十有八九就是这个原因。

4. 前后端分离联调与打包部署的实操

4.1 一个 IDEA 窗口管两个项目，怎么做最顺

做 Java 后端顺手写前端的人，最舒服的方式是把后端和前端放在同一个 IDEA 窗口里管理，而不是开两个编辑器。做法是先在 IDEA 里打开后端项目，再通过File → New → Module from Existing Sources把前端目录当模块加进来，或者更简单，把前端目录直接放在后端项目根目录旁边，用File → Open打开后端根目录后，手动把前端目录Add to Project。

要注意的是，别让 Maven 或 Gradle 把前端目录也当成构建资源扫描进去，否则每次构建后端都会处理一遍 node_modules 里的几万个文件，构建时间直接翻倍。在 Maven 里可以用<excludes>排除前端目录，Gradle 里用exclude配置排除。这个细节很小，但踩过一次之后构建速度的差距非常明显。

推荐的工作布局是这样的：后端服务跑在 8080，前端开发服务器跑在 5173，浏览器只访问 5173，前端发请求时统一带上/api前缀，由开发服务器在本地把请求转发到 8080。这样浏览器端不存在跨域问题，Cookie、请求头也都正常传递。

// vite.config.js 中的开发环境转发配置 server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } }

这段配置的意思是，前端代码里写fetch('/api/user/list')，开发服务器接住这个请求，转发到http://localhost:8080/user/list。rewrite那行负责去掉/api前缀，具体要不要去掉取决于后端接口本身有没有这个前缀，两边对齐就行。这个转发只在开发环境生效，部署到服务器上后，通常由 Nginx 承担同样的角色。

4.2 接口联调阶段最容易出的三类问题

第一类是路径对不上。前端写了/api/user/list，后端接口实际是/user/list或者/api/v1/user/list，差一个字符就是 404。排查方法很直接：打开 DevTools 的 Network 面板，看请求的实际 URL 和响应状态码，再和后端 Controller 上的@RequestMapping拼出来的完整路径逐段比对。养成把接口前缀抽成变量的习惯，改的时候只改一处。

第二个是登录态带不过去。前后端分离之后，登录信息通常放在请求头里传，前端需要在请求拦截器里统一加上。用 axios 的话，在request拦截器里从本地存储取出凭证塞进 headers 就行。要留意转发配置里的changeOrigin，它影响的是请求头里的 Host 字段，某些后端会根据 Host 做校验，配置不对就会出现本地直接访问接口没问题、走转发就 401 的现象。

// 统一请求封装示例，放在 src/utils/request.js import axios from 'axios' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use((config) => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( (res) => res.data, (err) => { console.error('请求失败', err.config?.url, err.response?.status) return Promise.reject(err) } ) export default service

第三类是响应体格式不统一。有的接口返回{code, data, msg}，有的直接返回数组，前端处理起来到处判断。这类问题建议在后端统一封装响应结构，前端拦截器里集中处理错误码，业务代码里只管拿data，能省掉大量重复判断。

4.3 打包和产物部署，路径问题要提前想清楚

打包命令就一句npm run build，但打完之后往哪放、怎么访问，决定了你会不会遇到白屏。默认打包出来的index.html里引用的是/assets/xxx.js这种以根路径开头的地址。如果你把整个 dist 目录部署在服务器的某个子目录下，比如http://域名/admin/，那么浏览器会去http://域名/assets/xxx.js找资源，必然 404，页面白屏。

解决办法是在vite.config.js里配base：

export default defineConfig({ base: './', // 相对路径，放哪都能跑 build: { outDir: 'dist', assetsDir: 'assets', sourcemap: false } })

base: './'是通用做法，代价是路由如果用 history 模式会有点小麻烦，因为相对路径在深层路由下解析会错。如果路由用了 history 模式，建议用子目录的绝对路径，比如base: '/admin/'，并且在服务器上把 Nginx 的try_files配好，让找不到的路径回退到 index.html，否则用户刷新页面就是 404。

Nginx 配置大致长这样：

server { listen 80; server_name your-domain.com; location /admin/ { alias /data/www/vue-demo/dist/; index index.html; try_files $uri $uri/ /admin/index.html; } location /api/ { proxy_pass http://127.0.0.1:8080/; } }

打包时还有两个容易忽略的开关。sourcemap: false关掉源码映射，产物体积能小不少，同时也避免源码直接暴露在浏览器里。build.chunkSizeWarningLimit可以把警告阈值调高一点，配合路由懒加载把大包拆开，首页加载速度会有肉眼可见的提升。

4.4 打包后布局异常，从哪几个方向查

"本地开发好好的，打包之后页面就乱套了"，这个问题几乎每个前端都遇到过。按我的排查经验，大概率出在下面几个地方，按这个顺序查基本能定位。

我自己遇过最典型的一次是组件库的样式没生效，查了半天发现是打包时 CSS 的提取顺序和开发环境不一致，全局样式被组件库的样式覆盖了。解决办法是在入口文件里明确控制引入顺序：先引组件库的样式，再引自己的全局样式，最后引页面级样式。开发环境因为模块加载顺序和打包不同，这个问题的表现可能完全不一样，所以每次做完样式相关改动，都建议跑一次 build + preview 验证，别等到上线才发现。

还有一个隐蔽的坑：某些第三方库在开发环境用 ESM 版本，生产构建时被解析成 CJS 版本，行为有差异。如果某个功能只在打包后失效，先去看这个库有没有文档里提到的"生产环境注意事项"，或者试试在配置里把它声明为外部依赖、通过 CDN 引入，很多时候就绕过去了。

5. 常见问题排查与避坑心得

5.1 环境类问题速查表

环境搭不起来是新手卡住最多的地方，我把高频问题整理成一张表，遇到时按症状对号入座，能省下大量瞎试的时间。

端口占用这个场景值得多说一句。Windows 上查端口占用并杀掉进程的两条命令是：

netstat -ano | findstr :5173 taskkill /PID 12345 /F

第一行的输出最后那个数字就是 PID，填到第二行里执行。更省事的做法是在 IDEA 的运行配置里把dev脚本设成默认，点停止按钮时 IDEA 会把整个进程树干掉，很少出现残留。

5.2 几个常规文档里不会写的实操心得

第一个心得是关于文件监听的。Vite 默认用系统原生的文件监听能力，在 Windows 本地磁盘上表现很好，但如果你的项目放在 WSL 的挂载目录、虚拟机共享目录或者网络映射盘里，热更新会时灵时不灵。这种时候可以在配置里开启轮询模式：

server: { watch: { usePolling: true, interval: 300 } }

代价是 CPU 占用会高一些，因为它是靠定时扫描而不是系统事件。本地开发能不开就不开，只有在确实排查到是监听问题时再打开。

第二个心得是关于提交前检查的。团队协作里最容易出现的低级错误是提交了带语法错误的代码，因为本地没有跑 lint。可以在package.json里加一个lint脚本，用 husky 挂到 git 提交钩子上，提交时自动检查，不通过直接拦下来。这套东西配一次，后面能省掉无数次"上线后才发现"的尴尬。

{ "scripts": { "dev": "vite", "build": "vite build", "preview": "vite preview", "lint": "eslint . --ext .js,.vue --fix" } }

第三个心得和热词里常见的那类应用场景有关。Vue 生态能做的事情远不止后台管理页面，比如用地图组件做配送路线可视化、用二维码扫描库做扫码入库、用视频播放组件做课程回放、用表格虚拟滚动处理十万级数据。这些场景在普通后台项目里都会被遇到，而它们对打包配置、按需引入的要求比普通页面高得多。我的建议是遇到这类需求时，优先找官方维护的组件库，别急着上那些下载量很低的小包，后期的维护风险差距很大。

第四个心得是关于版本升级的。前端生态的包更新很快，但不要无脑升级。npm outdated可以看哪些包有新版本，但升级前先看变更日志里的 breaking change 部分，尤其是大版本号的变化。稳妥的做法是小版本随便升，大版本单独开分支升，升完完整跑一遍核心业务流程再合并。我吃过一次亏，升了个大版本的表单库，结果自定义校验的写法全变了，返工花了一整天。

5.3 从能跑到跑得顺：一些长期有效的习惯

环境这东西，第一次搭是最费劲的，搭完之后把它固化下来就是长期收益。我的做法是维护一个自己的环境清单文档，记录 Node 版本、npm 镜像配置、IDEA 版本、装了哪些插件、每个项目的启动命令，换电脑或者重装系统时照着走一遍，半小时能恢复原样，不用再重新踩一遍坑。

项目层面，我习惯在根目录放一个 README，写清楚三件事：环境要求的最低 Node 版本、首次启动的完整命令序列、常见报错的排查入口。这份文档不仅方便别人，也方便三个月后的自己。很多时候我们不是不会，只是忘了当时是怎么弄好的，有一份记录就不用重新摸索。

IDEA 的配置也值得导出备份。File → Manage IDE Settings → Export Settings能把快捷键、插件列表、代码风格配置打成一个压缩包，换机器时导入就恢复，比重装一遍插件快得多。还有那个 IDEA 自带的本地历史功能，改崩了文件不用慌，右键Local History → Show History就能找回之前的版本，比 Git 还快一步。

至于工具本身，别陷入"配置半天却写不出代码"的循环。环境配到能跑通一个增删改查页面就够了，剩下的时间应该花在理解响应式原理、组件通信方式、路由和状态管理的设计思路上。工具是用来提效的，不是用来研究的。

我个人在这套组合里最大的体会是，真正浪费时间的从来不是装环境本身，而是遇到问题时的盲目试错。把每一步操作背后的原因搞清楚，把报错信息从第一行读到最下面一行，绝大多数问题自己就能解决。第一次搭这套环境我花了差不多一整天，现在重来一遍大概二十分钟，差距就在这些细节的积累上。