javascript booster能替代手动重构，但仅限语义安全的确定性转换，如var→const、function→箭头函数、if-else→三元运算符，所有操作均严格保持作用域与执行顺序不变。
JavaScript Booster 能不能替代手动重构？
能，但只在语义安全的范围内。它不是“AI猜你想怎么写”，而是基于 AST 分析做确定性转换，比如 var → const、function → arrow function、if-else → ?:，所有操作都严格保持变量作用域和执行顺序不变。
常见错误现象：选中函数体内部某一行点灯泡，结果弹出“Replace with template string”——这说明插件识别到了字符串拼接模式，但它不会跨作用域提取变量，也不会处理带副作用的表达式（比如 str + console.log('side effect') 就不会触发转换）。
- 必须把光标停在整条语句上（如整个
if块起始行），才能触发Replace with ?: -
Convert to const对已声明并赋值的let有效，但对后续有重新赋值的变量会直接禁用该选项 - 箭头函数转换后，
this绑定逻辑自动适配，无需额外检查
Prettier + ESLint 配合 JavaScript Booster 会不会冲突？
不会冲突，但配置顺序很重要。ESLint 负责规则校验（比如 no-unused-vars），Prettier 负责格式（比如引号、分号），JavaScript Booster 负责结构转换——三者职责不重叠。
容易踩的坑是：开启 editor.formatOnSave 后，先触发 Booster 重构，再触发 Prettier 格式化，中间若存在 ESLint 修复建议（如自动补分号），可能覆盖 Booster 的局部修改。所以推荐这样配：
- 关闭 ESLint 的自动修复（
"eslint.enable": false或禁用eslint.autoFixOnSave） - 保留
"editor.formatOnSave": true，但确保editor.defaultFormatter指向esbenp.prettier-vscode - 把 JavaScript Booster 当作“主动重构工具”，而不是“保存时自动运行”的后台任务
为什么 Live Server 和 Quokka.js 是 JS 编写阶段的硬需求？
Live Server 解决的是“改完 HTML/JS 后要不要手动刷新浏览器”这个高频打断点；Quokka.js 解决的是“这段逻辑到底跑不跑得通，要不要新建文件写测试”这个验证延迟问题。
使用场景差异明显：
- Live Server 适合整页交互调试，启动后 URL 是
http://127.0.0.1:5500/index.html，支持热更新但不支持断点 - Quokka.js 直接在编辑器内运行代码块，光标停在
console.log(x + y)上就能看到实时输出，支持console.table、debugger，但仅限当前文件上下文 - 两者可共存：用 Live Server 看整体效果，用 Quokka.js 快速验证算法片段
Snippet 插件和 JavaScript Booster 的本质区别在哪？
Snippet 是“模板复用”，JavaScript Booster 是“结构演化”。前者解决“重复写相似代码”，后者解决“已有代码怎么变得更现代”。
举个典型对比：
- 写 React 组件时，输入
rfc→ 触发 snippet → 生成函数组件骨架，这是预设模板 - 已有
function MyComponent() { return <div>hello</div>; }，光标停在function上 → 灯泡出现 → 选Convert to arrow function→ 变成const MyComponent = () => <div>hello</div>;，这是 AST 级重构 - 如果 snippet 里写了带
useState的模板，而你当前文件没引入 React，它照样插入——Booster 不会这么做，它只在语法合法、语义可推导的前提下才提供选项
真正复杂的不是功能本身，而是判断“什么时候不该用 Booster”：比如嵌套很深的条件链、带 try-catch 的异步逻辑、或依赖 this 指向的手动绑定——这些地方灯泡根本不会亮，得靠人来决定是否重构。
