ESLint 是唯一能提前揪出 undefined、no-unused-vars、eqeqeq 等逻辑隐患的工具，Prettier 专注格式统一，JavaScript Booster 负责安全重构；三者须按角色分工配置，否则易互相覆盖或静默失效。
ESLint 是唯一能真正提前揪出 undefined、no-unused-vars、eqeqeq 这类逻辑隐患的插件，Prettier 只管格式，JavaScript Booster 负责安全重构——三者缺一不可，但必须按角色分工配置，否则会互相覆盖或静默失效。
ESLint 必须本地安装并启用自动修复
全局安装 ESLint 会导致规则不生效或报 ESLint not found 错误，因为 VSCode 默认只读取项目内 node_modules 中的版本。同时，仅开启校验不启用修复，等于只亮红灯不刹车。
- 在项目根目录执行：
npm install eslint --save-dev，再运行npx eslint --init生成.eslintrc.js - VSCode 设置中必须添加：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，而非仅靠"editor.formatOnSave": true -
eslint.validate要显式声明语言类型，比如 React 项目需写["javascript", "javascriptreact"]，否则 JSX 标签不会被检查
Prettier 和 ESLint 冲突时优先关 ESLint 的格式规则
两者都管缩进、引号、分号，但 Prettier 更专注“怎么好看”，ESLint 更关注“有没有错”。若不协调，保存时可能反复来回改，甚至触发无限格式循环。
- 安装
eslint-config-prettier并在.eslintrc.js的extends末尾加入'prettier'，它会关闭所有与 Prettier 重叠的规则 - 不要在 ESLint 规则里写
semi或quotes，这些应交给.prettierrc管理，例如：{"semi": false, "singleQuote": true} -
editor.defaultFormatter必须设为esbenp.prettier-vscode，否则格式化行为由编辑器默认处理器接管，Prettier 不生效
JavaScript Booster 的重构建议只在光标悬停时触发
它不依赖配置文件，也不走 LSP 协议，而是靠 AST 分析实时生成上下文操作。这意味着：没光标定位，它就“看不见”代码；写了 var 却没把光标停在那一行，灯泡图标根本不会出现。
- 重构功能（如
Convert to const、Replace with ?:）只对当前光标所在语句块生效，跨多行的 if-else 必须把光标放在if关键字上 - 它默认不修改
console或debugger，也不会自动加use strict，属于“最小干预”型工具，适合渐进式升级旧代码 - 若发现灯泡不亮，先确认文件后缀是
.js（不是.ts或.jsx），且 VSCode 当前语言模式识别为 JavaScript（右下角状态栏查看）
复杂项目要区分开发/生产环境的规则强度
一个 no-console 在开发期设为 warn 是合理的，但上线前最好升为 error；no-debugger 同理。硬编码规则进 .eslintrc.js 会卡死 CI 流程，得靠环境变量或配置分层解决。
- 用
env字段区分场景，例如：env: { node: true, jest: true }开发时允许 Jest 全局变量，而生产构建时禁用 - CI 环境可通过
ESLINT_DISABLE_EXTENDS=true跳过extends链，直接加载精简版规则，避免第三方规则包拖慢 lint 速度 - 大型 Vue/React 项目建议拆分配置：根目录放基础规则，
packages/ui/.eslintrc.js单独加plugin:vue/vue3-recommended，避免规则污染
真正容易被忽略的是：ESLint 的 --fix 只修语法层面问题，比如补分号、删空格；JavaScript Booster 的重构能改控制流和表达式结构；而 Prettier 连 JSX 属性换行位置都敢动——它们动的是不同层级的代码，混用时得清楚每一刀切在哪。
