如何在VSCode中解决ESLint与Prettier的格式化冲突

ESLint 与 Prettier 冲突源于职责混淆：ESLint 应专注逻辑错误，Prettier 负责格式；需禁用 ESLint 格式规则、关闭其自动修复、确保 eslint-config-prettier 在 extends 末尾，并配置 VSCode 仅由 Prettier 格式化。

说到底，ESLint 和 Prettier 的冲突，根源往往不是工具本身有问题，而是我们没把它们的职责边界划清楚。一个应该专心抓代码的逻辑错误和潜在 Bug，另一个则专职负责代码的“颜值”和格式。只要把格式类的规则从 ESLint 手里剥离出来，同时管住它那双“爱动手”的自动修复功能，再确保配置的加载顺序不出错，编辑器里那些恼人的红黄波浪线，自然就消停了。

为什么保存后波浪线反复闪、代码越修越乱

典型的场景是这样的：你按下 Ctrl+S 保存文件，Prettier 立刻把 const a = 1 改成了 const a = 1;（加了个分号）。可紧接着，ESLint 就跳出来报错，提示“Missing semicolon”。这其实是因为，ESLint 检查的时机可能卡在了 Prettier 格式化完成之前，它看到的还是没加分号的原始代码。更糟糕的是，如果 VSCode 里 eslint.autoFixOnSa ve 和 editor.formatOnSa ve 这两个开关同时开着，它们俩就会像打乒乓球一样，轮流覆盖对方的修改结果，代码也就越改越乱。

• 问题的根本，通常不是版本不兼容，而在于 ESLint 依然在固执地检查那些纯属格式范畴的规则，比如 indent（缩进）、quotes（引号）、semi（分号）、comma-dangle（尾随逗号）。
• 配置顺序是关键。eslint-config-prettier 这个包必须出现在 .eslintrc.js 配置文件里 extends 数组的最后一位。否则，前面加载的配置（比如 airbnb 或 standard 的规则集）会把它覆盖掉，让它白忙一场。
• VSCode 的默认行为也是个“帮凶”。它本身并不区分“代码校验”和“代码格式化”这两个动作，导致两个插件都监听同一个保存事件。这就好比让两个人同时修改同一份草稿，不乱才怪。

如何配置 .eslintrc.js 让 ESLint 不再管格式

我们的目标很明确：让 ESLint 完全信任 Prettier 格式化后的输出，只去报告那些真正的“硬伤”，比如 undefined is not a function 这类运行时错误，而别再纠结于“这里应该缩进2个空格而不是4个”这种风格问题。

• 首先，安装必要的依赖包：npm install --sa ve-dev eslint-config-prettier eslint-plugin-prettier。
• 接着，在项目的 .eslintrc.js 文件中，确保 extends 配置项里包含了 "prettier"，并且它必须位于数组的末尾。例如：["eslint:recommended", "plugin:react/recommended", "plugin:prettier/recommended", "prettier"]。
• 为了更保险，可以显式地添加一条规则：rules: { "prettier/prettier": "error" }。这条规则的作用是，让 ESLint 把 Prettier 识别出的格式问题也标记为错误，但它自己不会动手去修复，把修复权完全交给 Prettier。
• 最后，记得清理掉所有手动编写的、与格式相关的 ESLint 规则。比如 "semi": ["error", "always"] 或者 "indent": ["error", 2] 这类，它们会直接和 Prettier 的配置打架。

VSCode 设置必须关掉 ESLint 的 auto-fix

很多人以为装好插件就万事大吉，其实不然。VSCode 默认可不会自动协调这两个“工人”谁该干什么。关键的配置开关，还得我们手动设置到位。

• 在 VSCode 的设置中搜索 eslint.autoFixOnSa ve，将其设置为 false。这一步至关重要，直接关掉 ESLint 在保存时的自动修复功能。
• 确认 editor.formatOnSa ve 设置为 true，并且将 editor.defaultFormatter 明确指定为 esbenp.prettier-vscode（即 Prettier 官方插件）。
• 为了防止不同语言文件的特例干扰，一个稳妥的做法是在项目根目录的 .vscode/settings.json 文件里进行针对性设置。例如："[ja vascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }。
• 注意，不要开启那个已经废弃的旧选项 prettier.eslintIntegration。这个配置会让 Prettier 反过来去读取 ESLint 的规则，等于又绕回了冲突的原点。

验证配置是否生效的三个硬指标

配置做完，不能光看编辑器里暂时没有波浪线就掉以轻心。得用下面三个动作来检验，看看结果是否符合预期：保存文件时是否只触发了一次格式化、ESLint 是否只报告逻辑错误、手动运行修复命令时它是否不动格式。

• 测试保存格式化： 打开一个函数，故意把缩进改成空格（假设 Prettier 配置用制表符），保存后观察它是否被统一修正为 .prettierrc 里定义的 tabWidth 格式，而没有被 ESLint 的 indent 规则再改回去。
• 测试规则静默： 删掉一行 console.log 语句末尾的分号。此时，ESLint 应该保持沉默，不再报错——因为 semi（分号）规则已经被 eslint-config-prettier 关闭了。但如果你的 .prettierrc 里设置了 "semi": false，那么 Prettier 会在你保存时，自动把这个分号删掉。
• 测试命令行行为： 在终端里执行 npx eslint src/ --fix。理想的输出结果里，不应该出现诸如 ✖ 123 problems (0 errors, 123 warnings) 这样大片的格式警告，而应该只包含像 no-unused-vars（未使用变量）或 no-undef（未定义变量）这类真正的逻辑错误。

这里有个最容易被忽略的坑：VSCode 的工作区设置和全局设置的优先级。即使你在项目的 .vscode/settings.json 里写得明明白白，如果用户之前在全局设置里把 editor.defaultFormatter 指定成了其他插件，那么全局设置依然会生效。所以，每次遇到一些诡异的、不符合预期的格式化行为，第一反应应该是打开命令面板（Ctrl+Shift+P），输入 Preferences: Open Workspace Settings (JSON)，直接查看当前项目真正生效的配置到底是什么，这样才能精准定位问题所在。