必须配ESLint是因为Prettier只负责格式化，不检测代码逻辑错误；ESLint则进行静态分析，识别undefined is not a function等潜在问题，二者职责互补，缺一不可。
ESLint + Prettier 是目前最可靠、团队协作最无痛的 JavaScript 代码质量保障组合，其他插件（比如 JavaScript Booster）属于锦上添花，但不能替代这两者的底层校验与格式化能力。
为什么必须配 ESLint 而不是只靠 Prettier
Prettier 只管“怎么写好看”，不管“有没有写错”。它不会报 undefined is not a function，也不会提醒你 console.log 漏在生产环境里。ESLint 才是真正做静态分析的那一个。
- 不装 ESLint 插件，
.eslintrc.js配置文件再全也等于没写——VSCode 根本不会读 -
eslint.validate必须显式声明语言类型，比如["javascript", "javascriptreact"]，否则 JSX 文件不生效 - 如果项目用 TypeScript，光配
javascript不够，得加typescript，否则any类型错误不会标红 - 规则里写
"no-console": "warn"，但 VSCode 默认不显示警告气泡，需开启editor.showUnused或依赖 Problems 面板
Prettier 和 ESLint 冲突时怎么破
二者都管引号、分号、空格，直接共存会互相打架。核心解法就一条：让 ESLint 放手，只留 Prettier 格式化。
- 装
eslint-config-prettier，并在extends数组末尾加上'prettier'，它会关掉所有和 Prettier 冲突的 ESLint 规则 - 不要在
rules里重复配置quotes、semi这类格式规则，Prettier 自己管 -
editor.defaultFormatter必须设为"esbenp.prettier-vscode"，否则右键「Format Document」可能调用错工具 - 若想保存时既修复 ESLint 错误又格式化，
editor.codeActionsOnSave要同时开"source.fixAll.eslint"和"source.organizeImports"（后者对 import 排序有用）
JavaScript Booster 这类重构插件怎么用才不翻车
它本质是“安全的快捷操作”，不是 AI 编程助手。灯泡提示（light bulb）只在语义明确、无歧义的上下文中出现，比如：
-
var→const可行，但let x; x = 1;→const x = 1;就不会触发，因为插件无法确认后续是否重赋值 - 箭头函数转换要求函数体是单表达式或带
return的块，含try/catch或多个if就不显示选项 -
Replace with ?:对嵌套三元、含副作用（如func()调用）的分支默认禁用，避免语义变更 - 别依赖它批量改旧代码——先手动跑
npx eslint --fix做基础清理，再用 Booster 点选精修
真正容易被忽略的是：ESLint 规则的启用范围默认只覆盖打开的文件，如果项目有 src/ 和 test/ 两个目录，但 .eslintrc.js 里没配 overrides，test 目录下的 describe 就可能逃过 no-unused-vars 检查。这种边界情况，比插件好不好用更影响代码质量底线。
