JavaScript Booster 的 light bulb 重构更安全，因为它基于 AST 分析作用域、变量引用和执行顺序，自动规避重赋值风险（如不将循环中 var i 转 const），支持行级生效、实时预览 diff、一键撤销且保持光标状态。
JavaScript Booster 的 light bulb 重构为什么比手动改更安全
它不是简单字符串替换，而是基于 AST（抽象语法树）分析作用域、变量引用和执行顺序。比如把 var str1 = 'jspang.com'; 转成 const str1 = 'jspang.com'; 时，插件会检查 str1 后续是否被重新赋值——如果存在 str1 = 'new value'，它根本不会显示“Convert to const”选项。
常见错误现象：直接全局搜索替换 var → const，结果在 for 循环里把 var i = 0 也改了，导致 i 变成块级作用域，循环崩掉。
- 它只对光标所在行或选中代码块生效，不污染其他上下文
- 所有转换都带预览，点击前能看到 diff，确认无误才执行
- 支持撤销（Ctrl+Z），且还原后光标位置和选区状态保持不变
通义灵码的行级补全触发时机和上下文依赖
它默认只在你停顿约 800ms 后自动弹出建议，但真正影响生成质量的是当前文件 + 引用链的上下文范围。比如你在 utils.js 里写 function formatTime(，它会自动读取同目录下 dateHelper.js 和 package.json 中的依赖声明，判断你用的是 moment 还是 date-fns。
容易踩的坑：在未保存的临时文件（如 Untitled-1）中测试，通义灵码无法读取项目结构，补全质量断崖式下降；另外，如果当前文件超过 500 行，它会主动截断上下文，忽略顶部的 import 声明。
- 手动触发快捷键：
Alt+P（Windows）或⌥P（macOS）可绕过自动延迟 - 在函数开头加 JSDoc 注释（如
/** @param {Date} d */）能显著提升参数推断准确率 - 避免在
node_modules或dist目录下打开文件，否则插件可能跳过分析
jsconfig.json 对智能提示的实际影响边界
它只解决模块路径解析问题，不参与类型推导或语法校验。比如你写了 import { debounce } from 'lodash'，但 VSCode 提示 “Cannot find module 'lodash'”，这时配 jsconfig.json 没用——得装 @types/lodash 或用 JSDoc 标注类型。
典型失效场景：项目用了 pnpm 的 pnpm link 或 monorepo 的 workspace 协议，jsconfig.json 的 baseUrl 和 paths 默认不识别这些路径别名。
- 必须放在项目根目录，且文件名严格为
jsconfig.json（不是tsconfig.json） -
paths中的 key 必须以*结尾，如"@utils/*": ["src/utils/*"]，否则路径映射不生效 - 修改后需重启 VSCode 或执行命令面板中的
Developer: Reload Window
Copilot 在 JS 中的注释引导为什么必须写具体
写 “// 处理用户数据” 这种模糊描述，Copilot 很可能生成一个空对象初始化或 console.log，因为缺乏输入结构、字段约束和副作用要求。但换成 “// 校验邮箱格式并返回 { valid: boolean, error?: string }”，它就能生成带正则和条件分支的函数。
性能影响常被忽略：Copilot 默认最多分析当前文件 500 行，如果你把长注释写在文件底部，而函数定义在顶部，它根本看不到——注释必须紧贴目标函数上方。
- 三段式结构最稳：功能描述 + 输入/输出明确标注 + 特殊约束（如“不能修改原数组”）
- 避免用 “优化一下”“改进这里” 这类指令，它无法判断你指哪段逻辑
- 如果函数涉及 DOM 操作，加上 “使用原生 API，不依赖 jQuery” 能过滤掉错误的库调用
真实项目里，light bulb 重构和 AI 补全不是互斥的——它们处理不同粒度的问题。一个负责安全、确定的语法升级，另一个负责模糊、开放的逻辑生成。关键在于别让 AI 替你做本该由人判断的事，比如变量命名意图或业务规则边界。
