javascript booster 能替代手动重构,但仅限于语义安全的局部变换,如 convert to const 或 replace with ?:,且仅对光标所在行或选中代码块生效,不跨函数作用域或处理嵌套过深三元链。

JavaScript Booster 能否替代手动重构?
能,但仅限于语义安全的局部变换。它不是万能重写器,而是把开发者反复验证过的重构模式封装成一键操作——比如 Convert to const 会检查变量是否被重新赋值,Replace with ?: 会确认分支中无副作用语句。一旦检测到潜在风险(如 if 块内含 return 或异步调用),灯泡图标直接不出现,避免误操作。
- 只对光标所在行或选中代码块生效,不跨函数作用域自动推导
- 不处理嵌套过深的三元链(如
a ? b : c ? d : e),这类需人工判断可读性 - 箭头函数转换后不会自动合并单参数的括号(
str => {...}不会变成str => ...),保留显式块结构更稳妥
ESLint + Prettier 配合 VSCode 自动保存时的冲突点
常见错误是 editor.formatOnSave 开启后,ESLint 的 fix on save 和 Prettier 同时触发,导致格式化结果反复震荡。根本原因是两者规则优先级未对齐——Prettier 管格式,ESLint 管逻辑,但 quotes、semi 这类交集规则必须由一方让步。
- 在
.eslintrc.js中必须加入extends: ['prettier'],否则 ESLint 会按自己规则加引号,Prettier 又删掉 -
eslint.validate设置里漏掉javascriptreact,JSX 文件里的 JSX 语法就不会被检查 - 若项目用 TypeScript,
parserOptions.ecmaVersion必须 ≥ 2021,否则可选链?.会被标为语法错误
通义灵码在复杂逻辑场景下的提示边界
它擅长补全 API 调用链(如 fetch().then().catch())和生成基础算法(快排、深拷贝),但对业务强耦合的复杂状态流转(例如电商结算页的多步骤校验+优惠叠加+库存预占)容易生成不可靠伪代码。关键在于:它依赖当前文件上下文,无法跨文件理解领域模型。
- 写注释比写代码更能引导生成质量,例如 // 计算用户可用优惠券列表(排除已过期、已使用、不匹配商品)
- 函数级补全(
Alt+P)比行级更稳定,因上下文窗口更大,但首次生成后务必检查this绑定和闭包变量引用 - 拒绝直接采纳带
TODO或FIXME的建议,这类标记往往是模型规避不确定性的信号
圈复杂度插件对真实工程的预警价值
它不是统计 if/for 数量那么简单。真正有用的是把 ComplexityAnalyzer 挂载到文件保存事件上,实时标出函数顶部的红黄数字——当某个函数复杂度从 8 跳到 12,说明最近一次修改引入了隐藏分支(比如新增的 try/catch 或条件渲染逻辑)。这时重构比等 Code Review 发现更高效。
- 默认阈值
11+是硬指标,但团队应根据历史故障率微调:高频出 Bug 的模块建议设为 7 - 它不分析
node_modules,但会扫描src下所有.js和.ts文件,包括测试文件 - 装饰器显示的数字是函数级粒度,不会细化到某一行,所以高亮位置在函数声明行而非具体条件语句











