vscode插件是javascript开发必备的生产力基础设施，而非可选附加；它通过ast驱动的智能重构（如var→const、if→?:）、prettier+eslint协同校验与格式化、intellisense类型推断及路径补全，实现保存即修正、语义级安全升级与团队规范统一。
VSCode 插件不是“锦上添花”，而是 JavaScript 开发中绕不开的生产力基础设施——没有它们，const 和 let 的自动转换、if 到三元表达式的安全重构、fs.readFile 的路径自动补全，都得手动敲、反复查、容易出错。
JavaScript Booster 能把 var → const / if → ?: 一键转准
它不靠快捷键触发，只在光标悬停时亮起左侧 ? 灯泡，点一下就完成语义等价的现代语法升级。关键在于它会检查变量作用域、避免副作用、保留原有执行顺序。
-
var str = 'hello';→ 点灯泡选Convert to const，自动加;并格式化 -
if (x) { a = 1; } else { a = 2; }→ 灯泡里选Replace with ?:，变成a = x ? 1 : 2; - 函数体里写
return 'hi ' + name;→ 光标停在该行，灯泡弹出Replace with template string，秒变return `hi ${name}`;
这类重构不是文本替换，而是基于 AST 的安全重写，比手写更可靠，比 ESLint 修复建议更主动。
Prettier + ESLint 组合让代码风格和质量不靠人盯
单靠 Prettier 格式化，解决不了 undefined 访问、未使用变量、== 误用这些逻辑问题；单靠 ESLint，又没法自动把 console.log 补全成 console.log('debug:', obj)。两者配合才是闭环。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 在
settings.json中启用"editor.formatOnSave": true和"eslint.enable": true -
prettier.semi和eslint.rules['no-unused-vars']冲突时，优先以 ESLint 规则为准（需设"prettier.eslintIntegration": false避免覆盖） - 项目根目录放
.eslintrc.js，配extends: ['eslint:recommended', 'plugin:prettier/recommended']，让报错和格式化规则对齐
保存即修正、保存即校验，团队里新人提交的代码不会因缩进或分号风格被拒，也不会漏掉 await 忘写这种低级错误。
IntelliSense 在 JS 项目里真能推断类型，不只靠 JSDoc
纯 JavaScript 项目没 .d.ts，但 VSCode 结合 @types/node、jsconfig.json 和路径智能补全（如 Path Intellisense），能让 require('./utils/ 按 Tab 就列出所有 .js 文件，fs. 后直接提示 readFile、writeFileSync 及其参数签名。
- 必须装
@types/node（npm install -D @types/node），否则fs、path等模块无类型提示 -
jsconfig.json中设"compilerOptions": { "checkJs": true, "allowSyntheticDefaultImports": true }，开启 JS 类型检查 - 路径补全依赖插件如
Path Intellisense，否则import里的相对路径只能靠记忆或手动翻文件夹
没有这些，data.map 后按点，大概率只看到 length 和 toString —— 因为编辑器根本不知道 data 是数组还是对象。
真正难的是插件之间的协作边界：Prettier 不管变量命名是否合理，ESLint 不管模板字符串怎么拆行，Booster 不介入异步流程改写。选哪个、怎么配、谁优先，得根据项目阶段判断——新项目从严，老项目求稳，CI 流水线里还得同步校验规则。工具链越顺，越容易忽略这些隐性契约。
