source.fixall.eslint 更精准，因为它通过 eslint 语言服务器直接修复 fixable 规则（如 no-unused-vars），而 editor.formatonsave 仅调用格式化器（如 prettier），无法处理规则类错误。
为什么 source.fixAll.eslint 比 editor.formatOnSave 更精准？
很多人误以为开启 "editor.formatOnSave": true 就能修复 ESLint 问题，其实它只调用格式化器（如 Prettier），对规则类错误（比如 no-unused-vars、eqeqeq）完全无效。真正触发 ESLint 自动修复的，是 source.fixAll.eslint 这个 code action —— 它走的是 ESLint 语言服务器的修复通道，只作用于标记为 fixable: true 的规则。
常见误区：同时开 formatOnSave 和 source.fixAll.eslint 可能导致冲突（比如 Prettier 改了引号，ESLint 又按规则改回去）。建议只保留后者，除非你明确需要格式化器处理非 lint 类风格（如 JSX 缩进宽度）。
eslint.autoFixOnSave 已废弃，别再用了
VSCode 旧版文档里常出现 "eslint.autoFixOnSave": true，但它早在 2021 年就被弃用，现在任何版本都无效。如果你在 settings.json 里看到这行，删掉它 —— 否则可能掩盖真实配置问题。
替代方案只有两个：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }- 配合
"eslint.run": "onSave"（确保只在保存时校验，省资源）
注意：source.fixAll.eslint 默认只对当前文件生效；若想批量修复整个工作区，得手动运行命令 ESLint: Fix all auto-fixable Problems（见下一条）。
手动触发全项目修复的快捷键和命令
保存时自动修复只管当前文件，但开发中常需一次性清理历史遗留问题。VSCode 提供了原生命令，无需插件：
- 快捷键：
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入ESLint: Fix all auto-fixable Problems回车 - 效果：遍历所有已打开的 ESLint 支持语言文件（
javascript、typescript、vue等），逐个执行修复 - 限制：不会扫描未打开的文件；若文件有语法错误（比如 JS 里写了
const a = {缺少闭合），ESLint 解析失败，该文件会被跳过
这个命令比 eslint --fix CLI 更轻量，适合日常小范围清理，但别指望它替代 CI 中的全量检查。
Vue/HTML 文件里 source.fixAll.eslint 不生效？检查 eslint.validate
默认情况下，VSCode 的 ESLint 扩展只校验 .js 和 .ts 文件。.vue 或内联 <script></script> 标签里的 JS 代码不会被自动识别，导致 source.fixAll.eslint 对它们静默失效。
必须显式声明支持的语言：
- 在 workspace 或 user settings.json 中添加：
"eslint.validate": ["javascript", "typescript", "vue", "html"] - 注意：
"html"是为了匹配 HTML 文件中的内联脚本；"vue"才能解析.vue单文件组件里的<script></script>块 - 如果用 Vetur，还要关掉它的模板校验（
vetur.validation.template设为false），否则和 ESLint 冲突
没配 eslint.validate 是 Vue 项目里自动修复“突然失灵”最常见的原因。
真正卡住人的地方往往不是配置本身，而是语言支持边界 —— 比如 JSX 中的 React Hook 规则、.vue 里 <style></style> 块的 CSS lint、或者 TypeScript 类型错误，这些都不在 source.fixAll.eslint 能力范围内。别硬试，先看 ESLint 输出面板里报的是什么规则，再查它是否标为可修复（fixable）。
