vscode中eslint自动修复不生效的根本原因是执行主体未对齐：必须安装本地eslint、确保配置文件位于项目根目录、启用"editor.codeactionsonsave": {"source.fixall.eslint": true}并禁用"editor.formatonsave"以防与prettier冲突。
VSCode 本身不带 Node.js 的 Lint 能力，eslint 必须由项目本地的 node_modules/.bin/eslint 执行；插件只是调度器，不是执行者。配置失败的主因几乎都是“执行主体没对齐”——比如装了插件但没装 eslint，或装了却没在项目根目录下生效。
为什么保存后 ESLint 不自动修复？
常见现象：改完 .js 文件一保存，缩进没变、分号没加、警告还在。这不是 VSCode 失灵，而是配置没匹配到真正的执行入口。
- 检查
package.json中是否已安装eslint和prettier（必须是devDependencies，不能只装 VSCode 插件） - 运行
npx eslint --version和npx prettier --version，确认命令可执行且版本兼容（例如 ESLint v8+ 需搭配@typescript-eslint/parser） - 多根工作区（multi-root workspace）中，每个子文件夹需各自有
.eslintrc.cjs或.eslintrc.js，否则 ESLint 插件默认只监听当前打开文件所在文件夹 - 若
.eslintrc.cjs里写了"extends": ["prettier"]但没装eslint-config-prettier，ESLint 会静默跳过整个配置，不报错也不生效
如何让保存时真正触发 ESLint 自动修复？
关键不是开一堆开关，而是明确谁负责哪一步：ESLint 做规则检查与语义修复（如 var → const），Prettier 做纯格式化（如引号、换行）。两者不能混用同一触发点。
- 关闭
"editor.formatOnSave"——否则 Prettier 会无脑重排，可能覆盖 ESLint 的修复结果 - 启用
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }——这是 ESLint 自动修复的唯一有效方式（eslint.autoFixOnSave已废弃） - 确保
"eslint.format.enable": true，这样 ESLint 才会接管 JavaScript/TypeScript 文件的格式化请求（注意：它只在有可修复规则时才介入） - 若想保留 Prettier 的最终格式化效果，应在 ESLint 配置中集成它：
eslint-plugin-prettier+eslint-config-prettier，而不是让它单独跑
如何避免 ESLint 错误地 lint 非 JS 文件？
ESLint 默认只对 .js、.ts 生效，但一旦你在根目录放了 .eslintrc.js，而项目里又有 Python 或 HTML 文件，VSCode 可能尝试对 .py 文件调用 ESLint，报错 Cannot find module 'eslint-plugin-python'。
- 在
.vscode/settings.json中显式限制 ESLint 检查范围："eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"] - 不要依赖全局
eslint，所有 lint 规则必须由项目级node_modules提供；全局安装会导致路径错乱、插件找不到配置 - 如果项目含多种语言，建议为不同语言子目录分别建
.eslintrc.cjs，并在其env和rules中精准限定作用域
最易被忽略的点是：ESLint 是否真正在项目目录下运行。哪怕 eslint --init 成功生成了配置，如果 node_modules 不在当前工作区根目录，或者 VSCode 打开的是父文件夹而非项目根目录，整个链路就断了——插件找不到二进制，也就不会触发任何动作。
