结论是：eslint 与 prettier 应各司其职——eslint 负责逻辑错误与质量检查，prettier 专注格式统一；需通过 eslint-config-prettier 消除规则冲突，并配合 vscode 的 codeactionsonsave 实现保存时自动修复，而非 formatonsave。
直接上结论：不用插件写 JS，就像徒手拧螺丝——能干，但效率低、易出错、后期维护成本高。真正提升专业度的关键，不是多装插件，而是选对 3 类核心插件并配好规则：静态检查（ESLint）、格式化（Prettier）、智能重构（JavaScript Booster）。其他插件只是锦上添花。
ESLint 配置必须关掉 no-console 吗？
不一定，但默认开 no-console 会干扰日常调试和快速验证。它在生产环境确实该禁用，但在开发阶段频繁报错反而掩盖真正问题。
- 推荐做法：设为
"no-console": ["warn", { "allow": ["warn", "error", "info"] }]，只拦debug和table这类易被遗忘的调试图语 - 注意
eslint.validate必须显式声明语言类型，否则 TSX 文件里 JS 片段可能不校验："eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"] - 如果项目用了
create-react-app，别手动装 ESLint 插件——它的内置 ESLint 已经接管，额外装会导致规则冲突和红色波浪线乱跳
Prettier 和 ESLint 规则打架怎么办？
不是“谁赢谁输”的问题，而是必须让 Prettier 只管格式、ESLint 只管逻辑。常见冲突点是引号、分号、逗号，解决方式很固定。
- 装
eslint-config-prettier并加到extends最后一项，它会自动关闭所有与 Prettier 冲突的 ESLint 规则 -
.prettierrc里别写semi: true，改用 ESLint 的semi规则统一管控——这样错误能进 Problems 面板，而不是静默格式化 - VSCode 设置里务必关掉
"editor.formatOnSave": false（如果用 ESLint 自动修复），改用"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，避免格式化和修复顺序错乱
JavaScript Booster 的灯泡为什么有时不亮？
它依赖 ESLint 或 TypeScript 语言服务提供 AST 支持，不是独立运行的。灯泡不亮，90% 是底层解析没起来。
- 确认当前文件是
.js或.jsx，且 VSCode 底部状态栏显示语言模式为JavaScript（不是Plain Text） - 检查项目根目录是否有
package.json，且含type: "module"或已安装eslint—— 它需要可运行的 ESLint 环境来分析作用域 - 函数转箭头时若含
this或arguments，插件会主动禁用该选项（这是正确行为），别误以为是 bug
最常被忽略的一点：所有这些插件的效果，都建立在你保存文件或触发校验的那一刻。不保存、不聚焦、不打开对应文件类型，再强的插件也等于没装。专业度不是靠插件堆出来的，而是靠每次保存时那一下“嗯，没问题”的确定感积累出来的。
