ESLint + Prettier + JavaScript Booster 协同提升代码健壮性：ESLint 拦截异步隐患（需启用 no-floating-promise 和 require-await）、Prettier 专责格式、Booster 提供安全重构，三者通过正确配置（如 extends: ['eslint:recommended', 'prettier']、禁用冲突规则、仅启用 source.fixAll.eslint）避免冲突，确保编辑器实时校验与精准修复。
JavaScript 代码健壮性不是靠“多写几行防御性代码”堆出来的，而是靠编辑器在你敲下 if、return 或 const 的瞬间，就帮你拦截常见隐患——比如未处理的 Promise、漏掉的 await、意外的 this 绑定、或裸露的 console。关键不在装多少插件，而在让 ESLint + Prettier + JavaScript Booster 各司其职、不打架。
ESLint 规则必须开 no-floating-promise 和 require-await
这两个规则是 JS 异步健壮性的底线。默认的 eslint:recommended 完全不包含它们，不手动加等于放任 Promise 被丢弃。
-
no-floating-promise：检测未被await、.then()或.catch()捕获的 Promise —— 这类代码看似运行，实则错误静默丢失 -
require-await：强制 async 函数内至少有一个await，避免把普通函数误标为 async 导致调用方误解返回值类型 - 配置写法（需安装
eslint-plugin-promise）：module.exports = { plugins: ['promise'], rules: { 'promise/no-floating-promise': 'error', 'require-await': 'error' } };
Prettier 和 ESLint 别在分号/引号上互相覆盖
一旦 prettier 和 eslint 对同一项（如 semi 或 quotes）都设了规则，就会出现保存时格式反复跳变、甚至修复失败。
- 正确做法：Prettier 全权负责格式（缩进、换行、空格），ESLint 只管逻辑和潜在 bug
- 在
.eslintrc.js中禁用所有与 Prettier 冲突的规则：extends: ['eslint:recommended', 'prettier']（注意顺序，prettier必须放在最后） - 确认 VSCode 设置里只启用一个格式化器：
"editor.defaultFormatter": "esbenp.prettier-vscode"，且关掉javascript.format.enable（原生 JS 格式化器会和 Prettier 抢）
JavaScript Booster 的重构建议要配合 ESLint 实时校验用
这个插件的灯泡提示（比如 Convert to const / Replace with template string）本质是安全的 AST 重写，但它不会检查语义是否合理 —— 比如把 let 改成 const 后，如果后续有重新赋值，ESLint 才会立刻报错 Assignment to constant variable。
- 必须确保 ESLint 在后台实时运行（
eslint.validate包含javascript），否则 Booster 的转换可能引入新问题而不自知 - 特别注意
Flip if-else和Replace with ?:：三元表达式在嵌套过深或含副作用（如函数调用）时可读性反而下降，ESLint 的no-nested-ternary和no-unused-expressions能补上这道防线 - 不要依赖 Booster 自动补分号 —— 如果你项目约定无分号，它强行加会导致 ESLint 报错，此时应关掉它的自动补全（插件设置里搜
autoInsertSemicolon）
editor.codeActionsOnSave 开关比 formatOnSave 更精准
很多人只开 editor.formatOnSave，结果每次保存都触发 Prettier 格式化，但真正需要的是“仅当 ESLint 能自动修复时才执行”。
- 推荐配置：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true } - 这样做的好处：只有 ESLint 明确支持自动修复的规则（如
semi、quotes、no-unused-vars）才会生效；而像no-console这类只报 warning 的规则，不会强制删掉你的调试语句 - 切忌同时开启
formatOnSave和fixAll.eslint—— 两者叠加可能导致代码被格式化两次，尤其在团队协作中容易引发 diff 冲突
最易被忽略的一点：所有这些配置都依赖项目级 .eslintrc.js 和 .prettierrc 文件真实存在且被 VSCode 正确识别。如果你打开文件后左下角没显示 ESLint 图标，或者灯泡不亮，第一反应不该是重装插件，而是检查当前工作区是否真在项目根目录下 —— VSCode 的规则加载是路径敏感的，跨文件夹打开单个 .js 文件，插件基本等于失效。
