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文件，包括测试文件 - 装饰器显示的数字是函数级粒度，不会细化到某一行，所以高亮位置在函数声明行而非具体条件语句
