JavaScript Booster不能替代手动重构，但能覆盖80%日常安全重构场景，仅在语义等价前提下触发操作，如Convert to const检查重赋值、Replace with ?:确认无副作用，遇return/throw等风险即禁用灯泡。
JavaScript Booster 能不能替代手动重构？
不能，但它能覆盖 80% 的日常安全重构场景。关键在于它只在语义等价的前提下触发操作——比如 Convert to const 会检查变量是否被重新赋值，Replace with ?: 会确认 if-else 分支无副作用。一旦检测到风险（如函数体内有 return 或 throw），灯泡就不会亮。这比盲目用正则替换或手写箭头函数更可靠。
为什么 ESLint + JavaScript Booster 搭配比单用 ESLint 更有效？
ESLint 告诉你“哪里错了”，JavaScript Booster 告诉你“怎么改才对”。比如 no-unused-vars 报错后，ESLint 不会帮你删掉那行；但把光标停在未使用变量上，Booster 的灯泡会直接提供 Remove unused variable 选项。再比如 eqeqeq 规则报 == 错误，Booster 可一键转成 ===，且自动处理字符串隐式转换的边界情况（如 if (x == null) → if (x === null || x === undefined)）。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
哪些重构操作容易踩坑？
-
Split into declaration and initialization：拆分后变量初始化时机改变，可能暴露undefined状态，尤其在 class 成员或闭包中要手动验证作用域 -
Flip if-else：反转逻辑时不会重排条件表达式，原if (a && b)反转后仍是if (!(a && b))，不是if (!a || !b)，需人工确认德摩根律是否适用 -
Convert to arrow function：丢失this绑定，若函数被用作事件回调或setTimeout参数，必须额外补.bind(this)或改用类字段箭头函数
如何让 Booster 和 ESLint 规则真正协同？
在 .eslintrc.js 中启用 eslint-plugin-prettier 后，Booster 的所有格式类操作（如引号、分号、括号换行）会严格遵循 Prettier 配置。但逻辑类重构（如条件转三元、函数转箭头）仍由 Booster 自主判断。这意味着：ESLint 负责守住底线（比如禁止 eval、强制 const），Booster 负责提升表达力（比如把多行 return 压缩成链式调用）。两者不重叠，也不冲突——前提是关闭 VSCode 内置的 javascript.validate.enable，否则会出现双重提示。
