eslint是代码进仓库前的第一道闸机，需配置.eslintrc.js并启用保存自动修复；prettier强制统一格式，应关闭vscode原生格式化并设关键选项；javascript booster提供语义等价重构；import cost标注入口体积预警。
ESLint：实时检测 + 自动修复的底线保障
没有 ESLint 的 JS 项目，相当于开车不系安全带——不是不能跑，但随时可能因 undefined、no-unused-vars 或 no-console 这类低级错误在 CI 阶段翻车。它不是“锦上添花”，而是代码进仓库前的第一道闸机。
- 必须配合项目根目录的
.eslintrc.js或.eslintrc.cjs使用，否则只报基础语法错，毫无意义 - 启用
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，保存即修复（但仅限可安全自动修复的规则，比如缩进、分号） - 和 Prettier 冲突时，别硬调规则，直接装
eslint-config-prettier关掉 ESLint 里所有格式相关规则——让 ESLint 管逻辑，Prettier 管样式 - React/Vue 项目务必加对应插件，如
plugin:react/recommended，否则useState未使用、key缺失等关键问题压根不报
Prettier：格式统一的“强制执行者”
团队里有人用单引号、有人用双引号，有人写 const a = 1，有人写 const a=1？Prettier 不跟你商量，它只做一件事：按配置把所有代码重写成唯一形态。这不是风格偏好，是协作刚需。
- 必须关掉 VSCode 原生的
editor.formatOnSave，改用 Prettier 作为默认 formatter："editor.defaultFormatter": "esbenp.prettier-vscode" -
.prettierrc里优先只设几个关键项：printWidth（建议 80）、semi（false 更现代）、singleQuote（true）、tabWidth（2） - 不要试图用 Prettier 格式化 HTML 模板字符串里的内容——它会破坏缩进逻辑，这类内联模板建议手动保持可读性
- Vue 的
.vue文件需额外配置"prettier.vueIndentScriptAndStyle": true，否则<script></script>里的缩进会错乱
JavaScript Booster：安全重构的“光标级操作”
当你想把 function foo() { return x + y; } 改成箭头函数，或把一长串 if-else 压成三元表达式，又怕手抖改出副作用？JavaScript Booster 的灯泡（?）就是为此存在——它不做猜测，只做语义等价转换。
- 光标停在任意函数声明上，点灯泡 → “Convert to arrow function”，自动处理
this绑定、返回值隐式、多参数括号等细节 - 选中
'hello ' + name + '!'，灯泡弹出 “Replace with template string”，转成`hello ${name}!`，连空格和标点都保准 - 对
if (a) { b = 1; } else { b = 2; }执行 “Replace with ?:”，结果是b = a ? 1 : 2;，且确保a只被求值一次 - ⚠️ 它不会帮你拆解复杂逻辑，比如把嵌套 for 循环转成
map/filter——那是你该写的单元测试没写全的信号
Import Cost：看不见的 bundle 重量警报
写 import { debounce } from 'lodash' 很爽，但实际打包进了 70KB 的 Lodash 全量代码？Import Cost 就在 import 行末尾标出估算体积，像一个永远开着的 bundle 分析器迷你版。
- 对 Tree-shaking 不完善的库（如早期版本 lodash、moment）特别有用，一眼识别“看似轻量实则沉重”的导入
- 显示数值单位是 KB，但注意这只是静态分析估算值，真实 gzip 后大小需以 Webpack/rollup 构建报告为准
- 搭配
lodash-es使用时，它能正确识别import debounce from 'lodash-es/debounce'为 ~1KB，而非全量 - 如果某行没显示体积，不是插件坏了，大概率是路径未解析成功（比如 alias 配置没被识别），检查
jsconfig.json中的paths是否生效
