ESLint 与 Prettier 冲突源于职责混淆：ESLint 应专注逻辑错误，Prettier 负责格式；需禁用 ESLint 格式规则、关闭其自动修复、确保 eslint-config-prettier 在 extends 末尾，并配置 VSCode 仅由 Prettier 格式化。
ESLint 与 Prettier 冲突不是工具问题，而是职责没划清：ESLint 应只管逻辑错误和潜在 bug，Prettier 才负责代码长啥样。只要把格式类规则从 ESLint 剥离、禁用其自动格式化、确保配置加载顺序正确，红黄波浪线就会消失。
为什么保存后波浪线反复闪、代码越修越乱
典型表现是：你按 Ctrl+S，Prettier 把 const a = 1 改成 const a = 1;（加了分号），ESLint 立刻报错 “Missing semicolon” —— 实际上它刚看到的是没分号的原始代码，而 Prettier 还没写入文件或写入后 ESLint 没刷新缓存。更糟的是，如果 eslint.autoFixOnSave 和 editor.formatOnSave 同时开启，两者会轮流覆盖对方结果。
- 根本原因不是版本不兼容，而是 ESLint 仍在检查
indent、quotes、semi、comma-dangle这类纯格式规则 -
eslint-config-prettier必须出现在.eslintrc.js的extends数组末尾，否则前面的配置（比如airbnb或standard）会把它覆盖掉 - VSCode 默认不区分“校验”和“格式化”，两个插件都监听
save事件，等于让两个人同时改同一张草稿纸
如何配置 .eslintrc.js 让 ESLint 不再管格式
目标是让 ESLint 完全信任 Prettier 的输出，只报 undefined is not a function 这类真问题，不报 Expected indentation of 2 spaces but found 4 这种风格问题。
- 安装依赖：
npm install --save-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 格式错误也当问题标出来，但不再自己修 - 删掉所有手动写的格式类 rule，比如
"semi": ["error", "always"]或"indent": ["error", 2]，它们会和prettier配置打架
VSCode 设置必须关掉 ESLint 的 auto-fix
很多人装完插件就以为万事大吉，其实 VSCode 默认不会协商谁来动代码。关键开关就在设置里，不是靠插件自动识别。
- 在 VSCode 设置中搜索
eslint.autoFixOnSave，设为false - 确认
editor.formatOnSave是true，且editor.defaultFormatter明确设为esbenp.prettier-vscode - 为防语言特例干扰，建议在项目级
.vscode/settings.json里写死："[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } - 不要开
prettier.eslintIntegration（已废弃），这个旧配置会让 Prettier 去读 ESLint 规则，反而绕回冲突原点
验证配置是否生效的三个硬指标
别只看有没有波浪线，要盯住三个动作是否符合预期：保存时只触发一次格式化、ESLint 只报逻辑错误、手动运行 eslint --fix 不动格式。
- 保存一个带空格缩进的函数，观察是否变成
tabWidth指定的空格数（来自.prettierrc），而不是被 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/settings.json 里写对了，如果用户全局设置了 editor.defaultFormatter 为另一个插件，它仍会生效。每次遇到诡异行为，第一反应应该是打开命令面板（Ctrl+Shift+P），输入 Preferences: Open Workspace Settings (JSON)，直接看当前项目生效的配置到底是什么。
