ESLint 和 Prettier 必须协同配置：ESLint 用 eslint-config-prettier 关闭格式规则，Prettier 负责格式化；VS Code 中仅启用 formatOnSave 并设默认 formatter 为 Prettier，关闭 ESLint 自动修复；no-console 设为 warn 并按需禁用；Vue/React/TS 项目需正确配置 parser 和插件。
ESLint 和 Prettier 是 JS 项目里最值得立刻配上的两个插件，缺一不可。光装不配，等于白装；配错顺序或规则冲突，反而让保存时疯狂报错。
ESLint 配不配 eslint-config-prettier？必须配
很多人装了 ESLint 插件，但没关掉它和 Prettier 冲突的格式类规则（比如 semi、quotes），结果一保存，ESLint 自动加了分号，Prettier 又删掉，来回打架。根本原因是：ESLint 默认包含一套格式规则，而 Prettier 的定位就是“只管格式，不管逻辑”。
- 必须在
extends数组末尾加入'prettier'（对应eslint-config-prettier包） - 不能只写
'plugin:prettier/recommended'—— 这个只启用 Prettier 的警告，不关闭 ESLint 原有格式规则 - 验证是否生效：打开一个 JS 文件，手动删掉结尾分号，按
Ctrl+S，如果没自动加回来，说明关成功了
Prettier 的 formatOnSave 和 ESLint 的 fixOnSave 别同时开
VS Code 设置里，editor.formatOnSave 和 eslint.enable 都默认开启，但如果你还手动开了 ESLint 的 eslint.codeActionsOnSave.fixAll，就会出现双引擎抢着改同一行代码的情况，尤其在 JSX 或带模板字符串的文件里容易崩格式。
- 推荐只开
editor.formatOnSave: true，并确保默认 formatter 是 Prettier（editor.defaultFormatter: "esbenp.prettier-vscode"） - ESLint 保留实时校验（标红/黄波浪线），但关掉自动修复：
"eslint.codeActionsOnSave": { "enable": false } - 需要批量修复时，手动执行
ESLint: Fix all auto-fixable Problems命令（Ctrl+Shift+P调出命令面板）
no-console 这类规则别直接设成 error
线上禁止 console 是合理需求，但开发阶段全拦死会卡住调试节奏。设成 error 后，哪怕只是临时加一句 console.log，保存就报错，还得手动注释掉——这不是省心，是添堵。
- 统一设为
warn，既提醒你别忘了删，又不打断流程 - 用
// eslint-disable-next-line no-console临时绕过，比删改再恢复快得多 - 更彻底的方案：加环境判断，比如只在
process.env.NODE_ENV === 'production'时才禁用console
Vue/React 项目里，vue-eslint-parser 或 @typescript-eslint/parser 少一个都报错
ESLint 默认只认纯 JS，遇到 .vue 单文件组件里的 <script setup>，或 TSX 里的类型标注，会直接跳过语法解析，导致规则失效甚至报 Parse errors in imported module。
- Vue 项目必须装
vue-eslint-parser，并在.eslintrc.js里指定：parser: 'vue-eslint-parser'，且parserOptions.parser指向@typescript-eslint/parser或babel-eslint - React + TS 项目要确保
parser是@typescript-eslint/parser，且plugins包含react和@typescript-eslint - 常见坑：装了插件但没在配置里显式声明
parser，ESLint 就当普通 JS 解析，defineProps这种语法直接报错
真正省心的维护，不是靠插件堆功能，而是让每个插件各司其职、边界清晰。ESLint 管逻辑和潜在 bug，Prettier 管换行缩进空格，谁也别越界——这点一旦没理清，后面所有配置都会变成救火现场。
