ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Vue3 + VS Code 插件清单:从 Volar 到 ESLint 的工程化配置指南

Vue3 + VS Code 插件清单:从 Volar 到 ESLint 的工程化配置指南 开始切 Vue3 项目的那段时间我做过最蠢的事就是把 VS Code 插件商店里的热门插件装了个遍结果编辑器比电脑还卡真正干活时总有几个插件在左下角疯狂报错。后来我重新梳理了一遍才发现 Vue3 开发真正需要的插件其实就那十几个关键不在于多而在于每一类功能都有个能打的。这篇不是我总结出来的“官方最佳实践”是我从 Vue2 切到 Vue3、又从零搭过四五个 Vite 项目之后沉淀下来的常用清单。里面有必装项、强烈推荐项、可选提升项也会把每个插件为什么要装、装完要改哪些配置说清楚。准备开始写 Vite Vue3 项目的同学或者从 Vetur 时代过来想换 Volar 的老开发都可以直接参考这套方案往下推。1. 内容整体设计与思路拆解1.1 为什么 Vue3 开发绕不开 VS Code 插件先说实话Vue3 本身并不可怕真正容易让人崩溃的是开发体验的断层。Vue 单文件组件SFC里同时混着 template、script、style 三段内容普通文本编辑器看到的只是一串没有结构的源码既不会高亮也不能跳转。VS Code 之所以能成为 Vue3 社区的主流选择靠的正是插件生态补齐了这块语言服务缺口。很多从 Vue2 切过来的老同事一开始都会顺手装 Vetur结果打开新项目发现模板提示全是乱的、script setup 语法识别不出来、ts 类型报错也不对位置。这不是 Vue2 时代那个老插件不努力而是 Vue3 的编译机制变化了template 里的表达式类型推断要跟 script setup 联动必须靠新的语言服务才能完成。Volar现在官方叫 Vue - Official就是这个定位。我把它当成整个插件体系的核心其他所有插件都是围绕它来补位。这段话其实已经说明了整体设计思路先解决“看得懂”的问题再解决“写得顺”的问题最后解决“改得稳”和“查得快”的问题。也就是说插件不是越多越好而是每一类能力都有人专门负责类与类之间不重复、不打架这样后期出问题排查成本也低。1.2 插件分类语言服务是核心工程化能力是骨架我在团队内部做环境规范的时候习惯把 Vue3 开发需要的插件先画成四个维度再按维度去挑具体工具。第一个维度是语言智能负责 Vue SFC 的语法高亮、代码补全、类型检查、跳转定义这一层 Volar 是绝对主力。第二个维度是代码规范负责 lint、格式化、错误提醒ESLint 和 Prettier 搭配干活。第三个维度是工程效率包括路径跳转、npm 包补全、Git 变更可视化、调试配置这些工具帮你把日常操作从“多点几次鼠标”变成“一按就到”。第四个维度是视觉辅助主题、图标、缩进高亮这类看似锦上添花的东西其实直接影响长代码的阅读体验。这四个维度拆开之后每个插件就有了明确的职责划分不会再出现两个插件都在抢格式化权、都在扫语法错误的情况。比如路径跳转我只需要 Path Intellisense不需要再装一堆带重名功能的“全家桶”插件Git 可视化我有 GitLens 就够了没必要再装十几个 Git 相关的扩展把它们的功能重复执行一遍。1.3 按需选型插件装多不是财富是负担我见过不少人一打开 VS Code 扩展面板就往下拉看到下载量高的就装最后左下角扩展图标变成一个小红点。插件本质上是常驻进程每个都会吃掉一点 CPU 和内存。Vue3 项目本身有 Vite 在监听文件、Vue 语言服务在做类型计算、ESLint 在实时校验这几个大件加起来内存就不小再叠加十几个无关紧要的扩展笔记本风扇就能转出共鸣声。所以我在整理这份插件列表时有一条硬性原则能通过配置文件解决的就不装插件能通过 VS Code 内置功能解决的也不装插件。比如代码缩进指示把editor.guides.indentation打开就行不装缩进高亮插件再比如括号着色VS Code 自带editor.bracketPairColorization同样不用额外装。2. 核心细节解析与实操要点2.1 语言智能核心Volar / Vue - Official 的正确姿势Vue3 项目的语言服务插件现在官方推荐名字叫 Vue - Official扩展 ID 是Vue.volar在扩展商店里搜“Vue - Official”或者“Volar”都能找到。注意别再去装 VeturVetur 对 Vue3 的 script setup 支持不完整两个插件同时开着还会互相抢资源出现莫名其妙的报错提示。装了 vue-official 之后要留意它接管 TypeScript 语言服务的问题。Volar 会自己启动一个 TS Server 来处理 .vue 文件和 .ts 文件里的类型信息如果你发现项目里类型提示没出来大概率是 Volar 的 server 没有正常启动或者跟 VS Code 内置的 TS/JS 语言服务冲突了。比较稳妥的做法是打开命令面板执行 “Volar: Restart Vue Server”把语言服务重启一下再看。补充一点TS 文件名以.vue开头的虚拟模块比如写import HelloWorld from ./components/HelloWorld.vue的时候Volar 会自动识别模块类型不需要手工写shims-vue.d.ts。但如果项目是从旧版本升级过来的src 目录下可能还留着这种类型声明文件里面内容过时反而会造成类型干扰建议删掉。2.2 代码规范三件套ESLint、Prettier、Error LensESLint 在 Vue3 项目里承担的是“逻辑审查”角色变量没用到、props 类型写错、watch 依赖数组漏了它都能在敲代码的过程中实时报出来。装 ESLint 插件之后记得在设置里配置一下 validate 范围让它可以自动校验 .vue 文件。光装插件还不够脚手架出来的项目一般自带 ESLint 依赖如果手动搭的工程可能还需要安装eslint-plugin-vue才能正确识别 Vue 文件规则。Prettier 管的是“格式审查”代码换不换行、用单引号还是双引号、分号要不要加这些交给机器去决定就别让团队里互相争论了。Prettier 插件有两个关键配置点一个是把editor.defaultFormatter设置为 Prettier另一个是打开editor.formatOnSave保存即格式化。但这里有个坑如果 ESLint 里也配了偏好格式的规则比如强制单引号而 Prettier 默认用单引号两者不冲突。可要是有人把 full-width、末尾逗号这类规则也塞进了 ESLint保存时就会看到改动反复横跳最后要么改配置文件要么打一架。最好的办法是把格式相关规则尽量交给 PrettierESLint 只守住逻辑类规则。Error Lens 是我非常推荐的一个小插件。它会把 ESLint 和 TypeScript 的错误信息直接内联显示在代码上不用等光标移过去才看到小黄条。刚用的时候可能觉得满屏红字很刺眼但长期用下来受益很大错误当场就能发现而不是编译时才报。建议配合编辑器主题一起调把 Error Lens 的透明度调低一点避免视觉污染。2.3 Vue3 专属语法效率插件Vue 3 Snippets 这类代码片段插件可以大幅减少重复劳动。以前写一个带 props、emits、slot 的组件至少得敲二十行脚手架我用片段插件半秒钟就生成。不过这类插件的质量参差不齐有的插件生成的是带any类型的模板反而引入隐患。建议选更新频率高的那种或者抄一份自己常用的组件模板存成 snippets本地维护一段 React 时间也不会吃亏。如果项目里用到 vue-router 和 pinia还值得装对应的智能提示插件。分享一个偷懒的做法直接在 vue-router 里打开文件跳到对应的视图组件在 Pinia store 里点击状态跳转到定义处。这些功能未必需要额外插件Volar 对 JS/TS 的 Go to Definition 已经支持得很好了关键是路径别名首选不提示。2.4 工程效率插件路径、Git、调试、拼写Path Intellisense 解决的是 import 路径补全问题。Vue3 项目里组件文件命名全是 PascalCase目录结构又很深凭手记路径一定会错。这个插件会读项目内的文件结构输入相对路径的时候自动补全完整路由。注意配置里最好加上对别名的支持否则import Layout from /layouts/index.vue时提示不出来。GitLens 排在很多人的必装列表里。它最常用的功能是查看当前行的最近修改记录、查 blame 信息以及在分屏视图里对比改动。新版本 GitLens 把基础功能免费化了日常看提交历史和 blame 足够用。如果对内存敏感可以关掉它比较重的 File History 视图只保留行内 blame 和代码透镜。Code Spell Checker 在中文环境里容易被忽略但英文注释和变量名拼写错误是真的能闹笑话的。它存在单词下划线提示还能给项目自定义加词表比如组件库名、业务缩写词。我经常写的变量config有时候敲成confg插件一眼就标出来了。2.5 AI 辅助插件的取舍原则这两年 AI 辅助编码插件已经不算新东西了从 GitHub Copilot、通义灵码、Codeium 到最近讨论度很高的 Codex、Claude Code 这类终端型工具风格差异很大。对于 Vue3 开发Copilot 和通义灵码这类内联补全对模板代码很友好写 table 列表、form 表单、重复的接口调用时效率提升明显。但有一点要提醒AI 工具在团队工程里不是简单的“装上就完事”。如果项目是公司核心业务代码装之前最好确认一下这些工具的数据会不会回传到第三方典型的做法是查一下公司内部的软件安全清单。我个人只把 AI 插件放在 Demo 项目和工具脚本项目里用核心业务仓库还是走得比较保守避免把公司内部的代码片段通过补全组件传出边界。3. 实操过程与核心环境落地3.1 从零创建 Vue3 项目并同步插件清单先看一个标准的 Vue3 Vite 项目创建过程假定我已经在 VS Code 里集成终端打开了某个目录。npm create vitelatest my-vue3-app -- --template vue-ts cd my-vue3-app npm install创建完用code .打开项目目录。为什么建议用vue-ts模板而不是纯vue因为 Vue3 和 TypeScript 的配合度已经很高了直接在起步阶段开启 TS 检查后面组件的 props 类型和事件类型都会明朗很多。如果你对 TS 还不熟至少也建议用vue模板加一个// ts-check的过渡状态别第一天就把式样敲死。单独一个人开发的时候插件装在自己机器上就行但团队协作时最好把推荐插件列表提交到仓库里。VS Code 支持.vscode/extensions.json文件里面声明当前项目需要哪些扩展其他成员打开项目时 VS Code 会提示安装。这个文件我用得很早解决了很多“我这边能跑啊你怎么跑不起来”的扯皮问题。{ recommendations: [ Vue.volar, dbaeumer.vscode-eslint, esbenp.prettier-vscode, christian-kohler.path-intellisense, eamodio.gitlens, usernamehw.errorlens, streetsidesoftware.code-spell-checker, EditorConfig.EditorConfig ] }团队规范里通常会加一条原则extensions.json里只写对项目有实际影响的插件不写个人偏好类的主题和图标插件。否则新成员一打开项目就凭空多装十几个不关心的扩展体验会变差。3.2 一份可以直接抄的 settings.json真正的开发体验往往藏在配置细节里。下面这份是我的基准配置配合上面的插件清单使用。{ editor.tabSize: 2, editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.bracketPairColorization.enabled: true, editor.guides.indentation: true, editor.inlineSuggest.enabled: true, files.eol: \n, files.associations: { *.vue: vue }, eslint.validate: [ javascript, typescript, vue, html ], eslint.format.enable: false, typescript.tsdk: node_modules/typescript/lib, path-intellisense.mappings: { : ${workspaceRoot}/src }, gitlens.codeLens.enabled: false, gitlens.currentLine.enabled: true, errorLens.messageEnabled: true, errorLens.messageTemplate: $severity: $message, cSpell.words: [ vite, unref ] }逐条解释几个关键项。eslint.format.enable要设为 false否则 ESLint 插件里自带的格式化工具会和 Prettier 争抢保存动作造成格式化结果不稳定。typescript.tsdk指向项目的本地 TypeScript而不是 VS Code 自带的那个版本这样才能保证类型判断和命令行里跑到的一样不会出现本地能过、CI 里报错的经典翻车。path-intellisense.mappings这行配置里把斜杠映射到 src 目录之后写import { getUser } from /api/user就能直接提示。files.eol统一成\n是因为很多 Vue3 项目在 Windows 上开发、Linux 上部署如果换行符不一致git 会提示整个文件都被修改了非常恶心。3.3 给 Vite 项目配一个断点调试环境很多人开发 Vue3 时调试只靠console.log虽然不丢人但遇到复杂状态流转就会很痛苦。VS Code 内置的 JavaScript Debugger 可以直接连接浏览器调试 Vite 项目配置非常简单在.vscode/launch.json里配一份启动配置。{ version: 0.2.0, configurations: [ { type: chrome, request: launch, name: Demo, url: http://localhost:5173, webRoot: ${workspaceFolder} } ] }注意这里url要和 Vite dev server 的默认端口一致Vite 默认是 5173如果改过端口就要同步改。调试前先启动npm run dev然后按 F5VS Code 会拉起一个新的干净浏览器实例断点就能在 .vue 文件的 script 部分起效果。这套方式对排查事件流、状态更新顺序的问题特别管用。插件层面不需要额外安装VS Code 从 1.75 左右开始就把内置调试器统一了以前那套 Debugger for Chrome 老扩展已经官方废弃别装了。4. 常见问题与排查技巧实录4.1 装了 Volar 还是没有任何代码提示先看 Vetur 是不是还在在扩展列表里搜 Vetur找到就卸载并重载窗口。然后执行命令面板里的 “Volar: Restart Vue Server” 重启语言服务。如果还不行打开设置搜索volar.takeoverMode.enabled旧版本需要把这个开关打开让 Volar 接管 TS 语言服务。现在的 Vue - Official 版本基本都是默认接管了不需要改成 strict。另一种情况是项目里存在残留的shims-vue.d.ts里面写declare module *.vue这行老声明会让 Volar 对整个 .vue 文件的类型推断失效新增属性全都不提示。我的处理办法是直接删掉只保留对特殊资源文件的声明比如图片、CSS module 这类。4.2 ESLint 和 Prettier 互相打架这个问题的典型表现是保存文件后Prettier 把单引号改成双引号ESLint 立刻又报红叉。根因在于 ESLint 里也配置了部分格式规则而你同时把它交给了 Prettier两边抢权。解决思路是格式化的活全给 PrettierESLint 只负责逻辑规则。如果项目里的 ESLint 配置是 old-school 继承制可以在规则里关闭与格式化相关的键比如quotes、comma-dangle、semi然后统一在.prettierrc.json里控制。prettier/prettier这个 ESLint 插件路由也可以帮你做一层兜底它会自动把 ESLint detect 到的格式偏好替换为 Prettier 规则声明。需要注意安装了eslint-config-prettier之后可能需要对旧规则做一次清除否则配置顺序不对咋改都没用。4.3 Vue3 Vite 局域网打开空白页这个问题经常出现在联调场景同事在同一个局域网内访问你的http://192.168.x.x:5173页面白屏或者一直加载不出来。原因通常是 Vite dev server 默认绑定localhost只监听回环地址局域网内访问不到。解决方案是把vite.config.ts里的 server 配置挪一下export default defineConfig({ plugins: [vue()], server: { host: true, port: 5173 } })host: true会让 Vite 监听所有网卡接口局域网就能访问。不过这个改动要放在defineConfig里重启一下npm run dev。值得一提的是如果访问之后白屏且控制台什么都没有还需要检查下是不是开了浏览器代理清理缓存之类的外部干扰。4.4 保存自动格式化不生效或者格式突然全乱了先确认右下角状态栏当前文件的语言模式是不是自动识别成了 Vue有些老文件没有正确关联会导致 VS Code 不触发 Prettier。手动处理方法是按住CtrlK M然后选 Vue。再检查editor.defaultFormatter是否被全局配置覆盖成其他插件比如某些项目级设置把 formatter 指定成了 Volar 官方那套。如果保存时 ESLint 也在修并且修完的顺序和 Prettier 冲突把eslint.format.enable设为 false 即可。还有个小坑VS Code 里跑 Prettier 有时会读取不到项目根目录的.prettierrc是因为工作区打开的目录层级不对。遇到这种情况直接打开项目的根目录再重载窗口。4.5 JSX/TSX、SCSS 和类型报错混杂的问题Vue3 项目不一定全是 .vue 文件有些复杂组件会写.tsx渲染函数或者封装公共组件库时直接写 JSX。Volar 对 JSX/TSX 的支持已经很好但在.tsx文件里写 JSX 语法时需要在文件顶部 import 对应组件并且确保tsconfig.json里jsxImportSource配置正确。常见的错误是把 Vue 的 JSX 当 React 写比如用className而不是classonClick而不是onClick with event modifier这类问题插件帮不了你只能靠经验。SCSS 支持相对简单在工程里安装sass依赖后style langscss就能编译。经常会遇到的问题是 Volar 对样式文件里的类名跳转支持得不够完整点击 template 里的 class 不一定能跳到 style 段。这不是你配置错误是语言服务边界问题想解决可以装 CSS Peek 这类辅助插件它在 .vue 文件的样式中跳转更灵活。不过要注意CSS Peek 和 Volar 在大型文件里偶尔有冲突装完记得实测跳转是否正常。4.6 插件越装越多编辑器卡到起飞每次新项目交接都会被问“你的 VS Code 为什么这么快”。其实关键就是控制后台进程的数量。解决办法是按 Cmd/Ctrl Shift P输入 “Developer: Show Running Extensions”看哪些扩展占用内存最高然后逐个评估要不要保留。GitLens、ESLint、Volar、Error Lens 这几个大件加起来就能吃掉不少内存如果还叠了五六个主题和图标插件编辑器不卡才怪。更合理的做法是给不同项目创建不同的 profile。VS Code 的 Profile 功能可以按工作任务区分配置和插件列表Vue3 日常开发用一套写 Markdown 博客用另一套处理 Python 脚本用第三套。切换 profile 不影响各自的插件加载启动速度和内存占用都能得到明显改善。写在最后从 Vue2 切到 Vue3 的那段时间我在插件配置上踩过不少坑最深的体会是Vue3 VS Code 这套组合真正起决定性作用的插件其实就那几个其余全是辅助。插件列表不是拿来攀比数量的它更像一个项目的基建配置对了你会忘记它的存在配置错了天天被它提醒“我不舒服”。如果你想越用越顺前期花二十分钟把.vscode目录下的配置提交进仓库让全组人都用同一套基础环境后面能省下来的解释成本远超过当时的投入。我自己每次升级 VS Code 或者碰到项目诡异的提示问题第一反应就是重启 Vue 语言服务、查 ESLint 配置、检查 Prettier 默认 formatter这三个动作能解决八成以上莫名其妙的毛病。
返回列表