javascript booster + eslint + prettier 构成实时反馈闭环，提升 js 编写弹性：booster 基于 ast 安全重构，eslint 报错、prettier 排版、booster 重构各司其职，需正确配置避免冲突。
JavaScript 代码写得越快，越容易出错；但光靠手动检查和反复调试，效率又太低。真正让 JS 编写过程“有弹性”的，不是某个万能插件，而是 JavaScript Booster + ESLint + Prettier 这三者在编辑器里形成的实时反馈闭环——改一行，立刻知道对不对；写完就自动整理，不打断思路。
为什么 JavaScript Booster 比手动重构更安全
它不是简单替换文本，而是基于 AST（抽象语法树）做语义级操作，所以不会误伤变量作用域或破坏闭包逻辑。
- 比如把
var str = 'a'转成const str = 'a'，它会先确认str后续没被重新赋值，否则不提供该选项 - 对
if-else转三元表达式，它只在分支都无副作用（如没调用console.log或修改外部状态）时才亮灯泡 - 箭头函数转换会自动处理
this绑定变化：如果原函数体里用了this，它就不会建议转成箭头函数
ESLint 和 Prettier 配合时最常踩的坑
两者职责不同，但配置冲突会导致保存后代码“越修越乱”，典型表现是：格式化完又标红、或者 eslint --fix 报错说“semi is not defined”。
- 必须装
eslint-config-prettier，并在extends里把它放在最后，关掉所有和 Prettier 冲突的规则 -
editor.defaultFormatter设为esbenp.prettier-vscode，但eslint.validate仍要保留，否则语法错误不提示 - 项目根目录下要有
.prettierrc，哪怕只写{"semi": false, "singleQuote": true}，不然 Prettier 用默认配置，和 ESLint 规则打架
哪些场景下 JavaScript Booster 真正省时间
它不解决“怎么写”，而是解决“写了之后怎么快速调优”，适合已有逻辑、想提升可读性或适配新规范的阶段。
- 把旧式函数表达式
function foo() { ... }批量转成const foo = () => { ... }，光标停在函数名上点灯泡就行 - 处理字符串拼接：
'hello ' + name + '!'→ 点灯泡选Replace with template string→ 自动变成`hello ${name}!` - 拆解复杂条件：把嵌套
if提取为提前返回，if (x) { if (y) { ... } }→ 选Convert to early return→ 变成if (!x) return; if (!y) return;
真正难的不是装插件，而是让它们彼此“不抢活”：ESLint 负责报错，Prettier 负责排版，JavaScript Booster 负责重构。三者共存时，任何一步出问题都会卡住整个流程——比如 .eslintrc.js 里漏写了 parserOptions.sourceType: 'module'，ESLint 就解析不了 import 语句，Booster 的灯泡也不会在模块导入行出现。
