eslint负责代码逻辑与规范检查，prettier统一格式，javascript booster保障安全重构，三者构成js代码管理铁三角；必须配置项目级.eslintrc.js并引入eslint-config-prettier以避免规则冲突，且需按技术栈扩展对应插件规则。
ESLint + Prettier + JavaScript Booster 是当前 JS 代码管理最稳的铁三角组合，缺一不可——ESLint 抓逻辑和规范，Prettier 统一格式，Booster 负责安全重构。单独装任何一个，都会漏掉关键环节。
ESLint 必须配项目级配置，否则只是摆设
只装插件不配 .eslintrc.js，ESLint 就只会报几个基础语法错误（比如 no-unused-vars），对实际开发帮助极小。它真正价值在于结合项目技术栈定制规则：
- Vue3 项目建议扩展
plugin:vue/vue3-recommended，否则<script setup></script>中的 props 解构、defineEmits 类型不会被校验 - React 项目要加
plugin:react/recommended和plugin:react-hooks/recommended，不然useEffect依赖数组遗漏不会报警 - 务必安装
eslint-config-prettier并在extends末尾引入，否则和 Prettier 的引号、分号规则会打架 - 本地没装全局 ESLint？插件会自动 fallback 到 VSCode 内置版本，但可能不兼容 TSX 文件——推荐在项目里
npm install eslint --save-dev
Prettier 自动保存格式化必须关掉“formatOnType”
editor.formatOnSave 开启是刚需，但 editor.formatOnType 建议关掉。原因很实际：
- 边写
if (a ===边触发格式化，括号自动补全后光标跳到奇怪位置，打断输入流 - JSX 中写
<div classname="</code">，还没输完类名就格式化，<code>=后面强行加空格，反而影响补全体验 - 多人协作时，如果有人开了
formatOnType，每次敲字母都触发重排版，Git diff 会出现大量无意义的空格变更 - 正确姿势：保留
"editor.formatOnSave": true，删掉或设为false的formatOnType - 光标必须落在整行语句上（比如
var x = 1的任意位置），不能只选中var或x，否则灯泡不亮 - “Convert to const/let” 对
function声明有效，但对const fn = function() {}不生效——得先用 Booster 把函数声明转成表达式 - “Replace with ?:” 只处理单 if-else 分支，且两个分支都必须有明确的赋值语句（
a = b ? c : d），带return或throw的不会转换 - 它默认不修改作用域外变量，比如闭包内修改外部
let，Booster 会拒绝转换并提示“unsafe”，这点比手动改靠谱得多 -
Path Intellisense：输入import {后，按Ctrl+Space能直接补全当前目录下所有.ts文件，不用手敲../../utils/ -
Import Cost：在import React from 'react'左侧显示~32.4KB，换import { useState } from 'react'立刻变成~1.2KB，数据真实可感 -
JSON to TS：后端给个user.json示例数据，右键 → “Convert JSON to TypeScript Interface”，直接生成interface User {...}，避免手写类型拼错字段名
JavaScript Booster 的灯泡重构不是玩具，是真能改生产代码
它那个左侧黄色灯泡图标不是装饰，是安全重构入口。但要注意触发条件和边界：
别忽略路径和导入的隐性成本
JS 项目里，import 写错、路径层级混乱、包体积失控，比语法错误更常导致构建失败或运行时白屏。这几个插件要同步启用：
复杂点在于：Booster 的重构能力依赖 ESLint 的 AST 解析结果，如果 .eslintrc.js 里关了 parserOptions.project（TS 项目常见），Booster 对泛型、联合类型的识别就会降级。这个细节，90% 的人装完就忘了调。
