ESLint插件需配置"source.fixAll.eslint":true才能启用自动修复，该配置必须置于editor.codeActionsOnSave对象内；Prettier与ESLint应职责分离，前者管格式后者管逻辑；JavaScript Booster提供安全重构能力，仅在语义等价前提下触发。
ESLint 插件必须配 source.fixAll.eslint
不配这个，自动修复就等于没开——哪怕你装了插件、写了 .eslintrc.js、甚至设置了 editor.formatOnSave，保存时依然不会修分号、引号、空格这些基础问题。
真正起作用的是这行配置：
{ "editor.codeActionsOnSave": { "source.fixAll.eslint": true } }
注意两点：source.fixAll.eslint 是键名，不能拼错；它必须放在 editor.codeActionsOnSave 对象里，不是平级字段。常见错误是把它和 editor.formatOnSave 混用，结果只格式化没修复。
- 如果项目同时用了 Prettier，建议保留
eslint-config-prettier，否则quotes、semi这类规则会和 Prettier 冲突，导致保存时反复“修-改-再修” -
eslint.validate要显式声明语言类型，比如["javascript", "typescript", "vue"]，否则 .ts 文件可能被忽略 - VSCode 1.89+ 默认启用 flat config，若项目还在用传统
.eslintrc.js，需在设置里加"eslint.useFlatConfig": false
JavaScript Booster 不是玩具，是安全重构入口
它不像 ESLint 那样报错，而是把重构操作“藏”在光标旁的灯泡里——但背后逻辑很严谨：只在语义等价前提下转换，比如 if-else → ?: 会检查分支是否无副作用，function → arrow function 会确认 this 绑定不受影响。
真正该用它的场景不是炫技，而是：
- 临时调试时拆分
let a = foo();成let a;+a = foo();，方便打断点 - 批量清理老旧代码里的
var声明，转成const/let，比全局搜索替换更准 - 把嵌套回调（如
fs.readFile）一键转为async/await，前提是函数已 Promise 化
别依赖它处理复杂逻辑——比如带 try/catch 的 if 块，它不会弹灯泡；它只做编辑器能静态推断的安全变换。
Prettier 和 ESLint 的边界必须划清
很多人把所有规则都塞进 ESLint，结果格式问题修不完，还和团队 .prettierrc 对不上。正确分工是：
- ESLint 管逻辑和规范：
no-console、eqeqeq、no-unused-vars - Prettier 管格式：
printWidth、tabWidth、singleQuote、semi（设为false） -
eslint-config-prettier是“关开关”，不是“加功能”，必须加在extends最末尾，否则前面规则会覆盖它
典型陷阱：prettier.semi 设为 true，但 ESLint 里又写 "semi": ["error", "never"]——两者直接打架，保存时编辑器会卡顿或静默失败。
规则生效前先验证配置加载路径
VSCode 不一定读你以为它该读的配置文件。常见失效原因：
- 项目根目录没放
.eslintrc.js，而是放在子文件夹里——ESLint 默认只向上查找一级 - 用了 monorepo，但没在
settings.json里配eslint.workingDirectories，导致子包的node_modules/eslint没被识别 - 本地安装了
eslint，但 VSCode 设置里eslint.packageManager错设为npm，而实际用的是pnpm
最快验证法：打开命令面板（Ctrl+Shift+P），运行 ESLint: Show Output Channel，看日志里有没有 “Using configuration from …” 和 “Failed to load config …” ——前者告诉你它读了哪份配置，后者直接暴露路径问题。
