让 Vue 代码永远整洁：Vetur 格式化的实战配置指南
你有没有遇到过这样的场景？
团队里两个人提交的.vue文件，一个用四个空格缩进，一个用两个；有人喜欢分号结尾，有人坚决不用；更离谱的是，保存一次代码自动“变形”——属性突然换行、引号莫名其妙变了……最后 Git Diff 满屏红色，根本看不出真正改了什么。
这背后往往不是态度问题，而是格式化工具没配对。尤其在 Vue 项目中，.vue文件包含 HTML、JS、CSS 三块内容，处理起来比普通文件复杂得多。而 Vetur 作为 VS Code 中最主流的 Vue 插件，既是救星，也可能成为混乱源头——关键在于你怎么用它。
今天我们就来彻底搞懂：如何让 Vetur 成为你和团队的“代码美容师”，而不是“格式破坏王”。
一、Vetur 到底是谁？别把它当成“格式化引擎”
很多人的误区是：装了 Vetur，就能自动把代码变漂亮。但真相是：
Vetur 不是格式化器，它是调度员。
你可以把它想象成餐厅里的服务员。顾客（开发者）点菜（触发格式化），服务员不亲自做饭，而是把订单分给厨房的不同区域——前端厨师做<template>，后端厨师做<script>，甜品师负责<style>。
每个区块最终由谁来“烹饪”？取决于你的配置。
它能调用哪些“厨师”？
| 区块 | 可选“厨师” |
|---|---|
<template> | prettyhtml（内置）、prettier |
<script> | vscode-typescript、prettier |
<style> | prettier、postcss等 |
默认情况下，Vetur 对模板使用自己的prettyhtml，对脚本可能走 TS 内建格式化。如果你又单独装了 Prettier 插件，系统就懵了：“到底听谁的？”——冲突由此而生。
所以第一步必须明确：我们只认一个老大 —— Prettier。
二、统一战线：为什么 Prettier 是最佳选择？
Prettier 被称为“有态度的格式化工具”，因为它主张“少配置，快决策”。一旦用了它，你就不再需要争论：
- 该不该加分号？
- 引号用单还是双？
- 函数括号前要不要空格？
这些问题的答案都写死在它的规则里。只要版本一致，所有人输出的代码长得一模一样。
更重要的是，Prettier 支持 Vue 单文件组件！这意味着我们可以让<template>、<script>、<style>全部交给它处理，实现真正的跨语言风格统一。
怎么告诉 Vetur：“以后全听 Prettier 的”？
打开 VS Code 的设置文件settings.json，加入以下配置：
{ "vetur.format.defaultFormatter.html": "prettier", "vetur.format.defaultFormatter.css": "prettier", "vetur.format.defaultFormatter.scss": "prettier", "vetur.format.defaultFormatter.less": "prettier", "vetur.format.defaultFormatter.js": "prettier", "vetur.format.defaultFormatter.ts": "prettier", "editor.defaultFormatter": "octref.vetur" }这几行的意思很直接：
- 所有语言块都优先用 Prettier；
- 整个编辑器的默认格式化器设为 Vetur（这样右键“格式化文档”才会生效）；
⚠️ 注意：光这么写还不够！你还得确保项目里真的安装了 Prettier。
三、项目级配置 > 个人偏好：别再靠“我本地看着舒服”
很多人图省事，在 VS Code 用户设置里全局开启 Prettier。结果呢？新同事拉下代码，发现格式不对；CI 流水线跑失败，提示“请运行 prettier –write”。
根源在于：格式规则应该由项目决定，而不是某台电脑上的插件版本或用户设置。
正确做法：把配置纳入版本控制
1. 安装项目依赖
npm install --save-dev prettier2. 创建.prettierrc文件
{ "semi": true, "singleQuote": true, "tabWidth": 2, "trailingComma": "all", "printWidth": 100, "arrowParens": "avoid", "endOfLine": "lf" }这些参数什么意思？
| 参数 | 实际影响 |
|---|---|
semi | 是否在语句末尾加分号 |
singleQuote | 使用'hello'还是"hello" |
tabWidth | 缩进用几个空格（推荐 2） |
trailingComma | 数组最后一项也加逗号：['a', 'b',] |
printWidth | 超过多少字符自动换行（通常 80 或 100） |
arrowParens | 单参数箭头函数是否加括号：x => xvs(x) => x |
这套配置现在成了项目的“宪法”，任何人只要运行npx prettier . --check都能得到相同结果。
3. 忽略不需要格式化的文件
创建.prettierignore：
/dist /node_modules /*.min.js /public防止构建产物被误格式化。
四、HTML 属性排版太丑？这是常见坑点
即使启用了 Prettier，你会发现<template>里的属性依然挤成一团：
<el-button type="primary" size="large" disabled @click="handleClick">提交</el-button>我们希望的是：长标签自动换行并对齐。怎么做到？
答案藏在 Vetur 的一个特殊配置项中：
"vetur.format.defaultFormatterOptions": { "js-beautify-html": { "wrap_attributes": "force-aligned" } }这里的js-beautify-html并不是指用 js-beautify 工具，而是 Vetur 在传递给 Prettier 前预处理 HTML 结构时使用的选项名。
可选值有三个：
"auto"：根据行长自动判断是否换行；"force"：每个属性强制独占一行；"force-aligned"：换行后属性名对齐（最常用）；
效果如下：
<el-button type="primary" size="large" disabled @click="handleClick" > 提交 </el-button>这才是清晰易读的模板写法。
五、ESLint 和 Prettier 能和平共处吗？
当然可以，但必须讲清楚“谁管什么”。
简单说：
-Prettier 管格式：缩进、引号、换行、分号；
-ESLint 管逻辑：变量未定义、防错、代码质量；
但如果两者都试图修改代码，就会打架。比如 ESLint 规则要求加分号，Prettier 也要求加分号，看似一致，实则可能因执行顺序导致重复操作或光标跳动。
解决方案：用eslint-config-prettier断后路
安装两个关键包：
npm install --save-dev eslint-plugin-prettier eslint-config-prettier然后更新.eslintrc.js：
module.exports = { root: true, env: { node: true }, extends: [ 'eslint:recommended', 'plugin:vue/vue3-recommended', 'prettier' // ← 关键！关闭所有与 Prettier 冲突的规则 ], parserOptions: { parser: '@typescript-eslint/parser' }, rules: { 'prettier/prettier': 'error' // ← 将 Prettier 错误提升为 ESLint 错误 }, plugins: ['prettier'] };其中'prettier'来自eslint-config-prettier，它会禁用掉 ESLint 中所有会影响格式的规则，避免双重管理。
而'prettier/prettier': 'error'则反过来，把 Prettier 的格式错误当作 ESLint 报错显示出来，统一反馈入口。
这样一来，你在编辑器里看到的所有波浪线，都可以通过“修复所有 ESLint 问题”一键解决。
六、自动化才是终极目标：保存即格式化 + 提交前拦截
手动格式化？早就过时了。
我们要的是：写完代码，Ctrl+S，一切自动归位。
1. 开启保存时自动格式化
回到settings.json：
{ "editor.formatOnSave": true, "editor.codeActionsOnSave": { "source.fixAll.eslint": true } }解释一下：
-formatOnSave: 保存时调用默认格式化器（即 Vetur → Prettier）；
-source.fixAll.eslint: 同时修复所有 ESLint 可自动修复的问题；
注意顺序：先格式化，再修复 ESLint，避免冲突。
2. 提交前兜底：Git Hooks 自动检查
就算有人关掉了自动保存格式化，我们还有最后一道防线。
使用 Husky + lint-staged，在git commit时只格式化变更的文件：
npm install --save-dev husky lint-staged npx husky init然后在package.json中添加：
"scripts": { "prepare": "husky install" }, "lint-staged": { "*.{js,ts,vue}": [ "prettier --write", "eslint --fix" ] }再创建.husky/pre-commit文件：
#!/bin/sh . "$(dirname "$0")/_/husky.sh" npx lint-staged从此以后，哪怕你忘记格式化，提交时也会被自动修正。想逃？门都没有。
七、那些年踩过的坑：常见问题速查手册
❌ 问题1：保存后代码反复变动，像抽风一样
原因：多个格式化源同时作用，如 Vetur + Prettier 插件 + ESLint 三方都在改。
解法：
- 明确唯一入口：建议以 Vetur 调用 Prettier 为主；
- 卸载或禁用其他格式化插件（如 Beautify）；
- 确保没有多个.prettierrc文件干扰；
❌ 问题2：TypeScript 类型报错却不提示？
原因：Vetur 默认不启用脚本校验。
解法：开启验证开关：
"vetur.validation.script": true这样 TS 类型错误、语法问题才会实时标红。
❌ 问题3：SCSS 嵌套样式格式错乱？
原因：Prettier 对 SCSS 支持有限，某些嵌套结构处理不好。
临时解法：局部关闭格式化：
<style lang="scss"> /* prettier-ignore */ .nav-item { &__link { color: red; } } </style>长期建议升级到最新版 Prettier，或考虑切换至 dprint 等替代方案。
最后一点思考：工具的意义是解放人
写前端这么多年，我发现高手和新手的最大区别之一，就是能不能把重复劳动交给机器。
代码格式从来不是“小事”。它直接影响协作效率、Code Review 质量、新人上手速度。当你每次都要花精力去调整别人的缩进、争论要不要加分号时，其实已经偏离了真正重要的事：业务逻辑、架构设计、用户体验。
而一套配置良好的 Vetur + Prettier + ESLint 组合拳，就像一位沉默的助手，默默帮你守住底线。你只需要专注创造价值，剩下的交给它。
所以，别再说“我习惯就好”。专业开发者的标志，是从不依赖“个人习惯”，而是建立可复制、可传承的工程规范。
现在就去你的项目里加上.prettierrc吧。也许下一个因此受益的人，正是未来的你自己。
