1. 先把三个插件的关系理清楚很多人一上手 Vue 项目第一件事就是去装 Vetur再装个 ESLint最后发现还要装 Prettier。然后呢格式化一会儿正常一会儿打架今天代码是单引号明天自动变双引号后天又全挂红灯。我见过太多同事在这种配置泥潭里挣扎一整天的了。先搞清楚一个底层问题这三样东西到底分别负责什么1.1 Vetur / VolarVue 文件的“母语翻译”Vetur 是 Vue 2 时代官方力推的 VS Code 插件核心能力是让 VS Code“看得懂”.vue单文件组件。没有它你在.vue文件里写template、script、style三块内容编辑器基本是半瞎状态语法高亮靠猜、补全靠运气、格式全靠手动。Vetur 之所以一度是标配是因为它确实做到了“开箱即用”装完就能高亮、能补全、能格式化。但它的底层架构是“套壳”各路语言服务对 template 部分调用 HTML 语言服务对 script 部分调用 JS/TS 语言服务一旦 Vue 组件的写法复杂起来比如 script setup 语法、TS 泛型组件、模板复杂表达式Vetur 的解析就会变得非常吃力甚至直接摆烂。所以 Vue 官方后来彻底转向了 VolarVue Language Features也就是 Vue 3 项目里推荐的那套语言服务插件。Volar 的架构完全不同它自己实现了 Vue 文件的完整解析链能精准识别script setup、模板中的类型检查、对编辑器指令提供更细粒度的支持。说人话就是Volar 才是 Vue 3 时代的“本地人”Vetur 已经属于“外来移民”了。这里有个很容易被忽视的认知Vetur、Volar 这类插件管的是“Vue 文件的解析和编辑体验”它们不负责“代码长什么样”也不负责“代码写得好不好”。长得帅不帅归 Prettier 管写得好不好归 ESLint 管分工不一样谁也替代不了谁。1.2 Prettier统一代码长相Prettier 解决的问题非常纯粹代码风格。单引号还是双引号、行宽多少、分号加不加、缩进用两个空格还是四个空格、换行怎么换。它就是那个“独裁者”不给你太多选项选项就那几个选完以后全项目一个长相谁也不用和谁吵。为什么要专门引入一个格式工具因为个人风格这东西人和人真的不一样。我就见过有人 Firefox 风格else单独一行和 Allman 风格大括号独占一行在同一个 PR 里互相“谦让”了四个回合。Prettier 的价值就是终结这类争论大家都不用选代码怎么样它说了算。Prettier 的哲学是“opinionated”它有自己的一套审美而且选项极其克制。你在 Prettier 里能配置的东西相比 ESLint 的 rules 少得可怜。但它有一个其他工具比不了的优势稳定。同一个文件100 台机器、100 个版本跑出来的结果必须完全一致这是它的底线承诺。所以 Prettier 从来不会“差不多就行”它会反复计算到最终稳定格式才输出。1.3 ESLint拦住脑残代码ESLint 的定位完全不同。它不仅仅是“排版”问题更重要的是代码质量。比如你声明了一个变量但从来没用到它有意见你 if 语句里忘了处理 else 分支它有意见你用了而不是它有强烈意见甚至你的函数太长了它也能给你整一条“圈复杂度超限”的警告。换句话说Prettier 管“长得帅不帅”ESLint 管“脑子好不好使”。这两者有部分重叠都对引号、分号、空格提出过要求但在职责上是能区分开的。这也是为什么现代项目里ESLint 和 Prettier 必须同时存在而且还要进行特殊配置否则它们俩会在引号、分号这种事情上互相顶牛。所以这节的核心结论是VolarVetur 的替代者负责看懂 Vue 文件Prettier 负责统一格式ESLint 负责代码质量把关。三者各管各的配合好了就是一个顺滑的开发环境配合不好那就是你工位上最磨人的小妖精。2. 为什么 Vetur 突然“不能装了”很多朋友最近发现在 VS Code 扩展市场里搜 Vetur要么搜不到要么显示“预发布”或“不再维护”要么装上了但 VS Code 提示“这个扩展已弃用请使用 Volar”。这不是你网络的问题也不是 VS Code 抽风而是历史进程真的走到这一步了。2.1 官方弃坑背景Vue 官方在 2021 年就开始在文档中把 Volar 作为 Vue 3 的推荐扩展到 2022 年、2023 年之后Volar 已经是 Vue 官方语言支持的唯一指定扩展。Vetur 的 GitHub 仓库基本处于冻结状态官方长期不更新。VS Code 市场后来干脆对 Vetur 进行下架或者标记为不可用所以你现在搜不到真的不奇怪——不是被“屏蔽”了而是它确实进入了生命周期尾声。这里我多说一句很多人以为“Vue 2 项目就应该用 VeturVue 3 项目才用 Volar”这是过时的理解。现在的 Volar 插件本身对 Vue 2 也有一定的兼容支持而且如果配合 Volar 的 takeover mode 或者新版 Volar 的自动模式它已经能覆盖 Vue 2.7 和部分老项目的场景。所以哪怕是老项目也不建议再费劲去折腾 Vetur 了。2.2 老项目与 Vetur 的处理方式如果你的机器上已经装了 Vetur但它明明没有“假死”甚至还能工作你可以先不着急卸载。但有两点必须注意同一工作区内Vetur 和 Volar 不要同时启用。这两个插件会同时抢占.vue文件的解析权结果就是百叶窗式的高亮、飘忽不定的补全、莫名其妙的类型报错。实测下来最典型的症状是模板里v-if下的变量跳转偶尔不识别代码补全时灵时不灵格式化结果时好时坏。如果你想切到 Volar干净的做法是在扩展面板里禁用 Vetur不是卸载也行但建议直接卸载然后安装 Vue Language Features (Volar)。装完之后重新加载窗口让 VS Code 重新初始化语言服务。如果你因为历史原因必须在一个老项目里继续用 Vetur那我给你一个折中方案用 Volar 打开新项目老项目保留一个专门的 VS Code Profile只在那个 Profile 里启用 Vetur。VS Code 的 Profile 功能是官方提供的可以封存一套扩展集合和设置互不干扰。这是我给很多从 Vue 2 迁移到 Vue 3 团队的建议实测能减少大量“为什么我打开这个项目就报错”的类型问题。3. 一套能落地的格式化配置方案说再多理论不如给一套能抄的作业。下面这套是我在多台电脑、多个项目里反复验证过的配置覆盖了 Vue 3 TypeScript ESLint Prettier 的常见组合。3.1 需要安装的插件清单以下是推荐安装的扩展按优先级排列插件名称作用是否必须Vue Language Features (Volar).vue文件语法高亮、补全、跳转必须Prettier - Code formatter代码格式化统一必须ESLint代码质量检查必须TypeScript Vue Plugin (Volar)配合 Volar 处理.vue内的 TS 类型检查如果是 Vue 3 TS 项目建议装推荐Path Intellisense路径补全辅助小功能选装注意如果项目里用的是 Vue 3 Vite那么这个组合基本是无脑配置Volar 负责 Vue 解析ESLint 负责质量检查Prettier 负责格式化。而 Vetur 确实可以彻底说再见了。3.2 关键配置项与逐行说明安装完插件后打开 VS Code 的用户设置Ctrl ,或者更好的是在项目根目录建一个.vscode/settings.json进行项目级配置。我强烈建议用项目级配置因为团队协作时每个人机器环境不同用户级配置很难拉齐。项目级配置提交到 Git 仓库所有人统一规则这才是正道。下面是我常用的.vscode/settings.json配置{ editor.formatOnSave: true, editor.defaultFormatter: esbenp.prettier-vscode, editor.codeActionsOnSave: { source.fixAll.eslint: true }, editor.tabSize: 2, editor.detectIndentation: false, files.eol: \n, [vue]: { editor.defaultFormatter: esbenp.prettier-vscode }, [javascript]: { editor.defaultFormatter: esbenp.prettier-vscode }, [typescript]: { editor.defaultFormatter: esbenp.prettier-vscode }, eslint.validate: [ vue, javascript, typescript, html ], eslint.codeAction.showDocumentation: { enable: true }, prettier.semi: false, prettier.singleQuote: true, prettier.tabWidth: 2, prettier.trailingComma: all, prettier.printWidth: 100 }我逐项说下为什么这么配editor.formatOnSave: true保存时自动格式化。这是提升开发体验最关键的一步不再需要手动Shift Alt F去格式化省心太多。它的副作用是如果格式化和 ESLint 规则冲突会在保存瞬间看到代码被“拉皮条”式地反复横跳这个我们稍后在常见问题里专门说。editor.defaultFormatter设置默认格式化器。这里明确指定为 Prettier防止和其他格式化器比如 VS Code 自带的 TypeScript 格式化器抢活。editor.codeActionsOnSave[source.fixAll.eslint]保存时自动执行 ESLint 的修复命令。这句是很多项目一开始没配的结果 ESLint 只报错、不自修体验极差。配置后保存时 ESLint 会自动修复可以自动修的问题比如去掉未使用的变量、补上缺失的分号等。files.eol: \n强制统一换行符为 LF。这一点在 Windows 和 macOS 混合开发的团队里特别重要否则 Git 经常提示整文件变更因为你文件里所有行尾都被改了。[vue]、[javascript]、[typescript]的editor.defaultFormatter按文件类型指定格式化器。为什么这里要单独给 vue 设因为 Volar 自己带了一个内置格式化器如果你不指定VS Code 可能会用小锤子去格式化 vue 文件结果就是v-if和模板语法被“格式化”得乱七八糟。现在这里强制指定为 Prettier就能保证.vue文件的格式化归 Prettier 管。eslint.validate告诉 ESLint 需要检查哪些文件类型。默认情况下 ESLint 对.js和.ts比较积极但对.vue和.html可能不闻不问。我在这里把vue、html加进去确保template部分的语法也能被覆盖。3.3 ESLint 与 Prettier 的冲突处理配置到这一步很多人会遇到一个经典问题ESLint 说要用双引号Prettier 说要用单引号俩人在保存的瞬间互相打架最终代码忽而单引号、忽而双引号像精神分裂现场。这就是 3.2 节里那个“拉皮条”死循环的来源。解决方案是安装两个穿梭机包npm install -D eslint-config-prettier eslint-plugin-prettiereslint-config-prettier的作用是自动关闭 ESLint 中所有与 Prettier 冲突的规则。言外之意是ESLint你只管代码质量排版那些破事先靠边站交给 Prettier。eslint-plugin-prettier的作用是把 Prettier 当作一条 ESLint 规则来跑。这样 ESLint 的报错列表里能直接显示 Prettier 的格式问题相当于在 ESLint 区域里又包了一层 Prettier 检查。然后在.eslintrc或eslint.config.js里做如下配置以比较通用的.eslintrc为例{ extends: [ vue-global, plugin:vue/vue3-recommended, prettier ], plugins: [vue, prettier], rules: { prettier/prettier: error } }核心就是两条extends里把prettier放最后注意一定要放最后这样它才能关闭前面规则和它冲突的部分rules里打开prettier/prettier: error让 Prettier 的问题在 ESLint 里直接以错误形式暴露出来。这里有个细节特别容易踩如果是 Vue 2 项目extends里用的可能是plugin:vue/vue2-recommended别搞混了。Vue 3 用vue3-recommendedVue 2 用vue2-recommended两者语义完全不同选错了规则集模板里的 ESLint 校验就会错得离谱。4. 常见报错与排查经验配置这种东西不跑是不知道有没有问题的。这一节我把自己在实际项目里遇到的一些典型问题整理成速查表附带解决方案你直接对照排查就行。问题现象根因解决方案保存后代码疯狂在单引号/双引号之间横跳ESLint 与 Prettier 规则冲突安装eslint-config-prettier和eslint-plugin-prettier确认.eslintrc中prettier在extends最后vue文件不格式化但js文件正常Volar 内置格式化器抢占了 Prettier 的位置在[vue]文件类型下明确设置editor.defaultFormatter为esbenp.prettier-vscode保存时报Cannot find module prettier项目本地没安装 PrettierVS Code 插件找不到执行文件在项目里执行npm install -D prettier全局安装也行但团队项目强烈建议本地安装ESLint 检查不到.vue文件eslint.validate里没加vue在settings.json中增加eslint.validate: [vue]Volar 已安装但.vue文件无高亮Vetur 和 Volar 同时在启用状态禁用或卸载 Vetur然后重新加载 VS Code 窗口格式化后v-if缩进混乱模板部分被 HTML 语言服务格式化而非 Vue 专用格式化器确认[vue]默认格式化器为 Prettier而非内置 HTML 格式化器保存时eslint只报错不自动修复codeActionsOnSave未配置或配置写法不对确认editor.codeActionsOnSave中包含source.fixAll.eslint: true除了这张表我再补充三个实操心得这些是文档里通常不会细写的第一ESLint 执行器的选择。VS Code 插件默认会优先使用项目本地的 ESLint如果本地没有就回退到全局。这个设计很合理但有时候会造成“本地装了新版本全局还是老版本”的混乱。排查啥也不生效的问题时先在终端手动跑一次npx eslint src/App.vue或你测试的文件如果命令行能正确报错但编辑器里不显示红块那就是 VS Code 插件与本地 ESLint 版本不匹配。新版 VS Code ESLint 插件对 8.x 和 9.x 的 ESLint 要求不同8.x 走.eslintrc9.x 支持eslint.config.js混合着配最容易出事。第二格式化生效顺序。如果你配完保存格式化不生效先打开命令面板Ctrl Shift P搜“Format Document”手动格式化一次看编辑器提示用哪个格式化器。有时候 VS Code 会脑洞大开地选一个你都没注意的扩展作为默认格式化器手动改一次就会弹出“你是否要设置为默认格式化器”点同意就完事了。第三团队协作时的配置统一。光有.vscode/settings.json还不够建议项目中放一个.editorconfig文件它不属于任何插件是跨编辑器规范VS Code 内置支持。这个文件专门定义缩进、编码、行尾等基础格式。我再贴一个常见配置供参考root true [*] charset utf-8 indent_style space indent_size 2 end_of_line lf insert_final_newline true trim_trailing_whitespace true [*.md] trim_trailing_whitespace false用 EditorConfig 的意义在于它连没有装 Prettier 的人也能保证基础的缩进和换行统一是团队协作的第一道防线。5. 针对具体项目的实战调整配置不是一锤子买卖不同项目的基础设施不一样实际要处理的问题也不一样。我见过太多人把一套配置从 Vue 2 的 Webpack 项目原封不动搬到 Vue 3 Vite 项目然后被各种报错折磨。5.1 Vue 3 Vite 项目Vite 项目通常不会安装vue/cli-plugin-babel/eslint那套东西而是 require 最新的eslint-plugin-vue和vue/eslint-config-typescript如果用了 TS。这种情况下ESLint 的配置文件和上面给出的样子基本一致但 eslint 版本最好升级到 8.x 或 9.x。如果用的还是老版本的plugin:vue/vue3-essential很难发挥 Vite 项目的全部功力。Vite 项目一个特殊点是模板表达式里的“未使用变量”检查在 ESLint 9 Volar 组合下会变得异常严格。比如你在template里用了v-for(item, index) in list但index没有实际使用eslint 会报 unused var。从语法上来说它确实是未使用变量但这个报错本身在某些业务场景下有些“矫枉过正”。如果团队觉得这种检查太烦可以在 eslint 规则里对vue/multi-word-component-names等规则做适当放宽否则新项目的文件名稍微不规范一点立刻满屏红灯。5.2 Vue 2 Webpack 项目如果你的项目还是 Vue 2那 P 个前缀提醒先把 eslint-plugin-vue 版本锁在 9.x 或更早版本然后把extends改成plugin:vue/vue2-recommended。Vue 2 项目里Volar 的支持相对弱一些但这不代表你就应该退回到 Vetur。Volar 的兼容模式能处理大部分 Vue 2.7 的语法只是老项目里的 Options API 加上各种 mixin类型推断确实不可能做到 100% 完美。这种情况下我的建议是保守使用 Volar但把 Volar 的检查级别调到 warning 级别避免干扰日常开发。具体配置可以在 Volar 插件设置里找到validation相关选项把 template 与 script 的检查都从 error 改为 warning。说白了老项目首要目标是别让工具把你劝退能把代码写顺、格式化统一就已经是胜利。5.3 纯 JavaScript 项目 vs TypeScript 项目纯 JS 项目配置最轻上面方案完全适用。但 TS 项目要额外注意typescript-eslint/parser的引入否则 ESLint 对 TS 语法会一片茫然。正确的是在.eslintrc中设置{ parser: typescript-eslint/parser, parserOptions: { ecmaVersion: 2020, sourceType: module }, plugins: [vue, typescript-eslint, prettier] }注意顺序typescript-eslint/parser是解析器它必须能正确理解 TypeScript 语法ESLint Prettier 才能愉快地在 TS 环境里继续工作。如果你是 Vite 创建的 TS 项目官方脚手架npm create vitelatest生成的模板已经内置了 ESLint 的完整配置链你只需要把 Volar 打开即可。唯一要留神的是把typescript-eslint/*插件升级到 7.x 以上版本老版本和 ESLint 9 会有兼容问题。6. 我的个人经验与建议在你踩进插件配置这个坑之前我想先分享几个真实的体会。第一个体会是格式化这件事一定要在项目创建的第一天就定好规则。我接手过一个从 2019 年开始的项目中间换了四五个人代码里既有单引号又有双引号既有分号又没有分号缩进既有两个空格又有四个空格。后来我花了整整一个下午加了 Prettier 并且跑了一整遍prettier --write结果改动了上千个文件连代码 review 都变得艰难因为 diff 里全是格式化变更真实改动被淹没在其中。所以如果你的团队还没有统一的格式配置越早统一成本越低。第二个体会是ESLint 和 Prettier 是两套工具不要混为一谈。我见过有人写规则时在 ESLint 的rules里手动配置semi: [error, never]然后再装 Prettier结果俩工具为了分号问题天天打架。正确做法是如果用了 PrettierESLint 里和排版相关的规则就尽量关掉让 Prettier 一家独大ESLint 专注代码逻辑和规范问题。这套分工模式说了很多年但是真到配置层面很多人还是hold不住屡错屡犯。第三个体会是Volar 上来了之后请忘掉 Vetur 的用法。Volar 的架构和 Vetur 完全不同它不像 Vetur 那样把.vue切成三段交给各自的宿主语言去处理而是自己维护了一个针对 Vue 文件的解析器和语言服务。这带来了一个好处模板里定义的变量在脚本里的类型提示也能联动。比如你在script setup里定义了const activeId ref(1)模板里使用时Volar 能给出确切的类型推断。这在 Vetur 时代是做不到的。所以如果有人和你说“Vetur 挺好的”或者“Vetur 能格式化那个文件”多半只是他在舒适区里待久了并没有真正感受到新工具链带来的效率提升。最后一次我给还没动手的你一句实在话配置这些东西最大的成本其实就是第一次动手那半小时。一旦你把这套配置通过.vscode/settings.json和.eslintrc沉淀到项目仓库里之后每个新人克隆下来就直接跑起来问题少一大半。这会是你这辈子做得最值的一次环境搭建投资。