JavaScript Booster 和 ESLint 是提升 JS 代码可控性的核心插件组合：前者提供零风险上下文重构（如 function→箭头函数、+→模板字符串），后者实现实时语义反馈与规则拦截；二者协同实现“怎么改”与“能不能写”的双重保障。

JavaScript 代码写得快不等于写得稳。真正提升可控性，靠的不是手速，而是编辑器能否在你敲下每一行时就给出语义反馈、安全重构选项和即时规则拦截——JavaScript Booster 和 ESLint 是目前最直接有效的两个插件组合，一个管“怎么改”，一个管“能不能写”。

JavaScript Booster 能做什么？不是所有灯泡都值得点

它不检查错误，只提供基于当前光标位置的上下文重构建议，核心价值在于“零风险转换”。但容易误用：比如在函数内部点灯泡，可能只重构局部变量；而在函数声明行点，才能触发整块结构升级。

• 常见错误现象：Convert to arrow function 后出现 ReferenceError: Cannot access 'xxx' before initialization —— 这是因为原函数用了 var 提升，而箭头函数没有，插件不会自动处理作用域迁移
• 使用场景：适合已有稳定逻辑的代码做语法现代化（如 function → =>、+ → 模板字符串），不适合边写边重构的草稿阶段
• 参数差异：无配置项，行为完全由光标所在语法节点决定；if 块上点灯泡才有 Replace with ?: ，return 行上点才有 Replace with template string
• 性能影响：纯前端运行，无网络请求或进程开销，响应延迟 Split into declaration and initialization 可能拆出冗余空赋值

ESLint 配置里哪些 rule 直接影响编写节奏？

很多团队把 no-unused-vars 设为 warn，结果变量一声明就飘黄线，反而干扰思路。真正影响“可控性”的是那些能阻止错误扩散的规则，而不是风格洁癖。

Browser Js

轻量级CDP浏览器控制，适用于AI代理。相较于内置浏览器工具，token消耗降低3‑10倍，仅在浏览时使用。

下载

• no-var：强制用 const/let，避免作用域混乱，写完立刻暴露提升问题
• no-undef：未声明变量直接报错，比运行时报 ReferenceError 提前至少 3 秒
• eqeqeq：禁用 ==，防止隐式转换导致的逻辑跳变，尤其在表单校验中极易踩坑
• 慎用 semi：设为 ["error", "always"] 会强制加分号，但配合 Prettier 时若没关掉 prettier.semi，保存时可能反复冲突

为什么 Prettier + ESLint 组合必须配 eslint-config-prettier？

不加这个包，quotes、indent、comma-dangle 这类规则会在 ESLint 和 Prettier 之间打架。你手动格式化一次，ESLint 又标红一次，最后要么关掉一个，要么放弃自动修复。

• 典型错误现象：保存后代码被 Prettier 格式化成单引号，但 ESLint 报错 Strings must use doublequote —— 这说明 eslint-config-prettier 没生效，或者 extends 顺序写反了（必须放在 prettier 最后）
• 兼容性影响：Vue/React 项目需额外加 eslint-plugin-vue 或 eslint-plugin-react，它们自带的格式规则也得被 eslint-config-prettier 关闭，否则照样冲突
• 配置示例（关键顺序）：

  module.exports = {
    extends: [
      'eslint:recommended',
      'plugin:vue/vue3-recommended',
      'prettier'
    ],
    plugins: ['vue'],
    rules: {
      'vue/multi-word-component-names': 'off'
    }
  };

  注意 prettier 必须是最后一个 extends 项

可控性的本质不是让代码看起来整齐，而是让每一次修改都可预期、可回退、无副作用。灯泡只帮你改写法，ESLint 告诉你哪步不能走，Prettier 确保没人能偷偷换缩进——三者缺一，就容易在“快速迭代”里埋下不可控的债。