vscode保存时自动eslint--fix需配置"editor.codeactionsonsave":{"source.fixall.eslint":true}、"eslint.enable":true等四项，且规则必须声明fixable，否则不生效。
VSCode 保存时自动触发 eslint --fix 的核心配置项
关键不在插件有没有装，而在于 VSCode 的 "editor.codeActionsOnSave" 和 ESLint 插件的协同逻辑。默认情况下，即使装了 ESLint 插件（由 dbaeumer.vscode-eslint 提供），它也不会在保存时自动修复——除非你显式告诉它“对哪些问题执行 source.fixAll”。
-
"editor.codeActionsOnSave"必须启用，且值为对象，不能是true或false - 必须写成
"source.fixAll.eslint": true，不是"source.fixAll"（后者会尝试调用所有语言服务器的修复能力，可能冲突或无效） - 如果项目里有
.eslintrc.*但没配"fixable"规则（比如用了"no-console": "warn"而非"error"），--fix对它完全无反应——ESLint 只修复标记为可修复（meta.fixable === "code"）的规则
为什么改了配置还是不生效？常见断点排查
最常卡在三个地方：插件未激活、工作区覆盖用户设置、或 ESLint 本身没被正确识别为项目依赖。
- 检查左下角状态栏是否有
ESLint图标亮起；没有说明插件没加载成功——确认已安装dbaeumer.vscode-eslint，且当前文件是 JS/TS（或你在eslint.validate中加了其他语言） - 打开命令面板（
Ctrl+Shift+P），运行Developer: Toggle Developer Tools，看 Console 是否报错"Failed to load plugin 'xxx'"——大概率是项目根目录缺少node_modules/eslint或eslint-config-xxx - 如果用了
yarn pnp或pnpm，VSCode 可能找不到本地eslint；此时需在工作区设置中指定路径："eslint.packageManager": "pnpm"或"eslint.runtime": "/path/to/node"
eslint --fix 在保存时的实际行为边界
它不是万能的“一键清理”，而是严格受限于 ESLint 规则自身的修复能力。比如缩进、分号、引号这些可推导的格式问题能修，但逻辑错误、变量重命名、API 替换不会动。
- 修复只作用于当前打开的文件，不会扫描整个项目（和 CLI 运行
npx eslint . --fix不同） - 若某行同时触发多个规则（如
semi+no-unused-vars），只有semi这类明确支持fix的才会生效；no-unused-vars默认不可修复，除非你用eslint-plugin-unused-imports等扩展 - 编辑器会跳过被
// eslint-disable-next-line或/* eslint-disable */注释屏蔽的代码块
推荐的最小可用配置片段（直接粘贴进 settings.json）
别堆一堆无关选项，下面这四行足够让大多数 JS/TS 项目跑起来：
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"eslint.enable": true,
"eslint.run": "onType",
"eslint.validate": ["javascript", "typescript", "javascriptreact", "typescriptreact"]
}
注意："eslint.run": "onType" 是为了让实时校验更灵敏（非必须），但如果你发现 CPU 占用高，可以改成 "onSave"；"eslint.validate" 一定要包含你实际编辑的文件类型，漏掉 typescriptreact 就会导致 .tsx 文件不走 ESLint。
真正麻烦的永远不是配置开关，而是规则集本身是否定义了 fix —— 比如你用的 eslint-config-airbnb 某个版本把 import/order 设为 warn，那它就不会在保存时自动排序 import。得翻对应规则文档确认它是否可修复。
