必须组合ESLint、Prettier与JavaScript Booster三类工具：ESLint检查逻辑错误但不自动格式化，Prettier统一格式但无法识别未使用变量等隐患，二者需通过eslint-config-prettier消除规则冲突，并显式配置.prettierrc及VSCode默认formatter，JavaScript Booster则提供经作用域与副作用分析的安全重构建议。
VSCode 插件本身不自动“维护”代码，但组合使用 ESLint、Prettier 和 JavaScript Booster 三类工具，能让绝大多数日常代码问题（格式错乱、语法隐患、重构低效）在保存或编辑瞬间被识别、修复或建议，真正把维护动作前置到写代码的每一秒。
为什么 ESLint + Prettier 组合不能只装一个
只装 Prettier：能统一缩进、引号、换行，但对 undefined 变量、未使用的参数、重复声明等逻辑问题完全无感；
只装 ESLint：能报错提示，但默认不自动修复格式类问题，且部分规则（如 max-len、indent）和 Prettier 冲突，导致保存时反复拉扯、光标乱跳。
- 必须用
eslint-config-prettier关闭 ESLint 中所有与格式相关的规则 -
prettier配置项（如printWidth、singleQuote）要显式写在.prettierrc或settings.json中，不能只靠插件默认值 - VSCode 设置里必须指定
"editor.defaultFormatter": "esbenp.prettier-vscode"，否则formatOnSave可能调用错 formatter
JavaScript Booster 的重构建议不是“炫技”，而是防错关键
它提供的每个灯泡选项（如 Convert to const、Replace with template string）背后都做了作用域分析和副作用判断。比如：
- 对
var转const前，会检查该变量后续是否被重新赋值，若存在则禁用该选项 -
Split into declaration and initialization不会拆开有初始化依赖的表达式（如let x = func(); let y = x + 1;） - 箭头函数转换时，自动处理
this绑定变化——如果原函数体内用了this，插件会拒绝转换或加注释提醒
真实项目中容易被忽略的配置陷阱
很多团队配完插件后仍频繁出问题，根源常在以下三点：
-
.eslintrc.js里没加env: { node: true, es2021: true }，导致??=、Promise.allSettled等新语法被误报为错误 - 项目根目录下没有
.prettierignore，导致node_modules、dist目录也被格式化，拖慢保存速度 - VSCode 工作区设置（
.vscode/settings.json）覆盖了用户级设置，但没同步到团队，造成本地格式化行为不一致
自动化不是装完插件就一劳永逸的事——真正的维护发生在配置细节里，而不是代码行数上。
