eslint插件需本地安装eslint包并正确配置规则才能生效，vscode插件仅作调度器；npx eslint --init初始化配置，rules需显式覆盖extends，eslint-config-prettier须置于extends末尾以禁用冲突格式规则。
ESLint 插件是提升 JavaScript 代码质量最直接、最有效的手段，但光装插件不配规则，等于没装。
ESLint 必须本地安装，不能只装 VSCode 插件
VSCode 的 ESLint 插件只是“调度器”，它本身不带规则引擎。如果项目里没装 eslint 包，插件会报错：ESLint not found，编辑器右下角弹出红色提示，Problems 面板里也看不到任何检查结果。
- 必须在项目根目录运行
npm install --save-dev eslint（推荐）或yarn add -D eslint - 全局安装
npm install -g eslint不可靠：不同项目可能依赖不同 ESLint 版本，全局版本容易冲突或缺失插件（如eslint-plugin-react） - 初始化配置优先用
npx eslint --init，它会自动识别项目类型（React/Vue/TS）、模块系统（ESM/CJS）、测试框架等，生成适配度更高的eslint.config.js（ESLint v9+ 默认 flat config）
rules 和 extends 冲突时，谁生效？
ESLint 规则优先级不是“后声明覆盖前声明”，而是按层级叠加 + 显式覆盖。常见误区是以为写在 rules 里的配置一定能 override extends 里的同名规则——实际要加 "off" 或明确设为 "error"/"warn" 才生效。
-
extends: ["eslint:recommended", "prettier"]中，prettier本质是关闭所有格式类规则（如quotes、semi），避免和 Prettier 冲突 - 如果想强制单引号，不能只写
quotes: ["error", "single"]，还要确保eslint-config-prettier已安装且在extends中靠后——否则prettier的关闭动作会被前面的规则覆盖 - 调试规则是否生效，可临时加一条
"no-console": "error"，然后写console.log()看是否标红；若不标，说明配置未加载或被覆盖
保存时自动修复，但有些问题它不敢动
editor.codeActionsOnSave 设为 {"source.fixAll.eslint": true} 后，Ctrl+S 会触发修复，但仅限 ESLint 标记为 fixable 的规则（比如 semi、no-unused-vars）。逻辑类问题（如 no-undef、react-hooks/exhaustive-deps）不会自动改，只提示。
- 修复失败常见原因：代码有语法错误（如少括号），ESLint 解析失败，整个文件检查中断
- 某些规则修复会改变语义（如把
var改成const时，变量后续被重新赋值），ESLint 会跳过，避免引入 bug - 想批量修复全项目，终端运行
npx eslint . --fix，但注意：它不会处理未被eslint.ignorePatterns排除的 node_modules 或构建产物
Prettier 和 ESLint 协作，关键在配置顺序
两者分工明确：Prettier 负责“怎么排版”，ESLint 负责“写得对不对”。但它们的配置文件（.prettierrc 和 eslint.config.js）如果规则打架，保存时会出现格式反复横跳——比如 ESLint 要加分号，Prettier 去掉，再保存又加回来。
- 必须安装
eslint-config-prettier，并在extends数组中放在最后，确保它能关掉所有与 Prettier 冲突的 ESLint 格式规则 -
.prettierrc里只放格式相关项：printWidth、tabWidth、singleQuote、trailingComma，不要放semi这类 ESLint 管的项 - VSCode 设置里禁用
editor.formatOnSave对 ESLint 的干扰，只留"editor.defaultFormatter": "esbenp.prettier-vscode"，让 Prettier 专管格式，ESLint 专管逻辑
真正卡住人的往往不是插件装不上，而是规则没加载、修复没触发、或者两个工具互相 undo。盯着 Problems 面板和终端报错，比盲目调设置更有效。
