ESLint 和 Prettier 冲突的本质是职责未分离导致的重复格式化
先说一个核心判断：ESLint 和 Prettier 本身并不“打架”。真正的问题，往往出在过时的桥接方案和混乱的自动化流程上。
你猜怎么着？很多开发者还在用 eslint-plugin-prettier 这类工具，试图让 ESLint 去运行 Prettier 的规则。这其实已经是个过时的做法了。更麻烦的是，当 VSCode 的 editor.formatOnSa ve 和 ESLint 的自动修复功能同时开启，两套工具会对同一段代码重复操作——一个忙着调整换行，另一个执着于修改缩进，结果就是互相覆盖，最终导致格式错乱或者满屏的红线报错。
那么，正确的思路是什么？答案是：职责彻底分离。让 Prettier 专心做它最擅长的格式化工作，而 ESLint 则回归本源，专注于代码质量检查和有限的逻辑修复。具体来说，需要做到以下几点：
- 在 ESLint 的配置中，果断禁用所有与格式相关的规则，比如
indent（缩进）、quotes（引号）、semi（分号）这些，统统交给 Prettier 来统一管理。 - 在 VSCode 里，关闭 Prettier 扩展的自动格式化功能，避免它与 ESLint 的保存时修复产生冲突。
- 最关键的一步：将 ESLint 扩展设置为默认的格式化工具，并开启它的格式化能力开关。
VSCode 设置里必须改的三项关键配置
光有思路不够，配置才是落地关键。打开 VSCode 的设置（快捷键 Ctrl+, 或 Cmd+,），找到下面三项配置并确保它们准确无误，缺一不可：
"editor.formatOnSa ve": true—— 保存时格式化必须保持开启，但前提是默认的格式化工具已经指向了 ESLint。"editor.defaultFormatter": "dbaeumer.vscode-eslint"—— 明确指定由 ESLint 扩展来接管所有格式化工作。当然，这需要你先安装好eslint和vscode-eslint扩展。"eslint.format.enable": true—— 这是激活 ESLint 格式化能力的核心开关。开启后，ESLint 会读取项目中的 Prettier 配置来执行格式化。请注意，这个功能依赖于项目根目录存在.prettierrc和正确配置的eslint-config-prettier。
这里有几个常见的坑需要避开：不要再去设置 prettier.eslintIntegration（这个选项在新版 Prettier 扩展中已经移除了），也千万不要手动把 editor.defaultFormatter 绑定到 prettier-vscode 上。
项目级配置文件怎么写才不踩坑
编辑器配置好了，项目本身的配置文件才是地基。你的项目根目录下，需要同时存在 .eslintrc.cjs（或 .eslintrc.js）和 .prettierrc 两个文件。
ESLint 配置的要点在于，要显式地关闭所有格式规则。下面是一个标准的配置示例：
// .eslintrc.cjs
module.exports = {
extends: [
'eslint:recommended',
'plugin:react/recommended',
'prettier' // ← 这行必须放在最后，它会覆盖前面所有扩展中的格式类规则
],
plugins: ['react'],
rules: {
'no-console': 'warn'
}
};
- 安装与排序：务必通过
npm install --sa ve-dev eslint-config-prettier安装这个包，并在extends数组中将'prettier'放在最后一位。这个顺序至关重要，它能确保 Prettier 的配置正确覆盖掉其他规则集里的格式要求。 - 各司其职：
.prettierrc文件就只负责定义格式风格，比如{"semi": false, "singleQuote": true}，保持简洁，不需要额外插件。 - TypeScript 项目：如果用的是 TypeScript，除了安装
@typescript-eslint/eslint-plugin，同样需要eslint-config-prettier。配置时，'prettier'依然要排在extends数组的末尾。
保存后还是格式错乱？检查这三件事
配置都写对了，但一保存代码还是乱？别急，问题通常出在以下几个隐蔽的角落：
- 工作区设置覆盖：检查一下项目目录下的
.vscode/settings.json文件。有时候，工作区设置会覆盖你的全局用户设置，如果里面误写了"editor.defaultFormatter": "esbenp.prettier-vscode"，那么前面的所有配置都会失效。 - ESLint 未正确加载：在项目终端里运行
npx eslint --version，确认 ESLint CLI 可用。如果报错，很可能项目根本没有安装eslint，或者版本过低（建议使用 8.0 及以上版本）。 - 文件类型识别错误：留意 VSCode 右下角的状态栏，看看当前文件的“语言模式”是什么。如果它被识别为
plaintext或普通的ja vascript，ESLint 可能会跳过对 JSX 等语法的检查。确保它显示的是ja vascriptreact或typescriptreact。
还有一个更隐蔽的情况，常出现在 monorepo 项目中：VSCode 打开的是某个子包的目录，但 ESLint 的配置文件却在项目根目录。这时，ESLint 扩展可能找不到正确的配置。解决办法是在子包的 .vscode/settings.json 中，显式指定工作目录："eslint.workingDirectories": ["./"]。
