vs code 中 prettier 与 eslint 协作的唯一正确方式是：eslint 仅检查逻辑错误，格式化完全交由 prettier；需关闭 eslint 格式化（"eslint.format.enable": false）、设 prettier 为默认格式器、启用 codeactionsonsave 修复，并确保配置作用域一致。
VS Code 里 Prettier 和 ESLint 不打架的唯一前提：让 ESLint 只检查逻辑错误，把所有格式决定权彻底交给 Pretterrc 文件。 其他任何“两边都修一点”“先 ESLint 再 Prettier”的思路，都会在保存瞬间触发代码抖动、波浪线反复闪、甚至 Git 提交里全是空格变更。
为什么 prettier/prettier 规则报错却修不了
这是最典型的职责混淆信号。当你看到 ESLint 报 prettier/prettier 错误（比如 “Expected indentation of 2 spaces but found 4”），说明 ESLint 已识别出格式问题，但没动手修——因为它被明确禁止了格式化权限。
- 根本原因：
eslint-config-prettier确实关掉了 ESLint 自带的indent、quotes、semi等规则，但它不会自动开启“用 Prettier 修复”的能力 - 必须显式启用：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }—— 这条才真正让 ESLint 在保存时调用 Prettier 去落地修复 - 常见漏配：只开了
formatOnSave却没开codeActionsOnSave，结果格式错误只标红不修正
editor.defaultFormatter 必须设为 esbenp.prettier-vscode
VS Code 默认会用内置的 JavaScript/TypeScript 格式器处理 JS/TS 文件，它和 Prettier 规则完全无关。哪怕你装了插件、写了 .prettierrc，只要这行没设对，按 Shift+Alt+F 或保存时调用的就不是 Prettier。
- 绝对不要设成
dbaeumer.vscode-eslint—— 这会让 ESLint 插件尝试格式化，直接和 Prettier 冲突 - 工作区级设置优先于用户级，建议在项目根目录
.vscode/settings.json中写死："editor.defaultFormatter": "esbenp.prettier-vscode" - 验证方式：右键编辑器 → “Format Document With…” → 看默认项是不是 Prettier，而不是 “Configure Default Formatter…”
eslint.format.enable 必须为 false
这个设置是隐形冲突源。它的默认值是 true，意味着 ESLint 插件会主动监听保存事件并尝试格式化——哪怕你已指定 Prettier 为默认格式器。两个格式器同时抢着改同一段代码，结果就是光标乱跳、代码被拉成一行、Vue 的 setup() 函数缩进全崩。
- 必须手动关掉：
"eslint.format.enable": false - 它和
"editor.formatOnSave": true不矛盾：前者禁用 ESLint 的格式能力，后者启用 VS Code 的格式触发机制，由 Prettier 执行 - 如果团队用 TypeScript，额外加一句：
"typescript.preferences.includePackageJsonAutoImports": "auto"，避免类型导入干扰 ESLint 缓存
真正容易被忽略的是配置加载顺序和作用域边界：.prettierrc 只对 Prettier 生效，eslint-config-prettier 只影响 ESLint 的规则开关，而 VS Code 的 settings.json 控制谁在什么时候动文件。三者不在同一层，不能互相覆盖，只能靠人工对齐。一旦某处写错位置（比如 prettier 放在 extends 数组中间），或者某项设置落在用户全局而非工作区，整个链路就断了。
