eslint 插件必须启用，否则静态检查形同虚设；需配合本地安装、有效配置文件（如.eslintrc.js）、vscode中显式开启validate、prettier协同配置及安全重构实践，才能实现准确、高效、可维护的代码质量保障。
ESLint 插件必须启用，否则静态检查形同虚设
不装 ESLint 插件，就等于关掉了 JavaScript 的“语法雷达”。它不是锦上添花，而是基础防线——能提前发现 undefined 变量、未使用的参数、== 误用、异步函数忘记 await 等典型错误。
关键操作点：
- 安装插件后，必须在项目根目录存在
.eslintrc.js或.eslintrc.json，否则插件默认只启用极简规则，几乎不报错 - VSCode 设置里要显式开启验证：添加
"eslint.validate": ["javascript", "javascriptreact"] - 若项目用 TypeScript，需额外加
"typescript"到 validate 数组，否则.ts文件不被检查 - 常见坑：全局安装了 ESLint 但项目本地没装
eslint包，插件会静默失效，终端报ESLint not found
Prettier + eslint-config-prettier 组合才能避免格式冲突
Prettier 负责把代码变“整齐”，ESLint 负责判断它“对不对”；两者规则重叠时（比如引号、分号），不协调就会互相打架——保存时格式化一次，ESLint 又标红一次。
实操要点：
- 必须安装
eslint-config-prettier，并在.eslintrc.js的extends数组末尾加上'prettier' - VSCode 设置中指定默认格式化工具为
esbenp.prettier-vscode，同时关闭editor.formatOnSave的自动触发，改用editor.codeActionsOnSave控制：
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
这样既保留 Prettier 的格式能力，又让 ESLint 在保存时统一修复风格类问题，不重复执行。
JavaScript Booster 提供安全的重构操作，不是所有“转换”都可靠
JavaScript Booster 的灯泡重构（如 Convert to const、Replace with ?:）看起来很爽，但它依赖 AST 分析，对复杂作用域或副作用语句可能误判。
使用前提：
- 只对简单声明、纯表达式条件语句生效；遇到
try/catch、for...in、含this或闭包引用的函数，灯泡常不出现或提示“unsafe” - 重构前务必确认光标落在整条语句上（而非某单词），否则可能只改局部，破坏逻辑
- 它不会修改
import/export语句，也不处理 class 成员方法的箭头化，别指望它覆盖全部现代语法迁移 - 建议配合 Git 暂存区预览：执行重构后，立刻看 diff，确认变量作用域、求值顺序是否变化
Path Intellisense 和 Auto Rename Tag 是减少低级错误的实际防线
拼错路径导致模块导入失败、改了开标签却漏掉闭标签——这类错误不触发 ESLint，但高频发生且难定位。
它们的作用边界很清晰：
-
Path Intellisense在import或require时补全相对路径，支持node_modules内部包名提示，但对动态字符串拼接路径（如require('./' + name)）无效 -
Auto Rename Tag仅作用于静态 HTML/JSX 标签，对模板字符串里的 HTML（`<div>${x}</div>`）或 Vuev-html内容不生效 - 两者都不校验语义，比如补全了一个不存在的文件，或重命名后组件 props 未同步更新——它们防手误，不防逻辑错
真正影响 JS 代码准确性的，从来不是“写得快”，而是“改得准、引得对、查得到”。插件只是杠杆，支点永远在你对代码结构的理解上。
