Prettier 是 JS 代码格式化的强制底线，必须安装、配置并启用；需在 VS Code 中设置默认格式化器为 Prettier 并开启保存时自动格式化，配合 .prettierrc 文件和 ESLint 协同分工，确保团队协作一致性。
Prettier 是 JS 代码排版的底线，不是“可选”，而是必须装、必须配、必须用。 其他插件可以锦上添花，但没它，格式混乱、团队 diff 狂飞、PR 被拒都是常态。
为什么 Prettier 不能只靠“装了就完事”
VS Code 默认不启用任何格式化器，There is no formatter for 'javascript' installed 这个报错，90% 是因为漏了两步：没设默认格式化器、没开保存时自动格式化。
- 必须在设置里搜
Editor: Format On Save并勾选 - 必须搜
Editor: Default Formatter，下拉选esbenp.prettier-vscode - 首次右键 →
Format Document With时，如果弹窗卡住，手动点选Prettier并勾选 “始终使用此格式化器” - 项目根目录加
.prettierrc文件，哪怕只写{"semi": true, "singleQuote": true}，也比没强
JavaScript Booster：重构不是改样式，是改语义
它不碰缩进空格，专治“写法陈旧”。光标停在代码上，左侧黄色灯泡一亮，就能安全转换语法结构。
-
var str = 'a'→ 点灯泡选Convert to const，自动补分号、转单引号 -
function foo() { return x + y; }→ 灯泡 →Convert to arrow function，再点return行灯泡 →Replace with template string -
if (x) { a = 1; } else { a = 2; }→ 灯泡 →Replace with ?:，生成a = x ? 1 : 2;，且确保x不被重复求值 - 它不修改作用域、不引入副作用，所有转换都通过 AST 分析，不是字符串替换
ESLint + Prettier 协同：谁管什么，边界必须清
很多人把 ESLint 当格式化工具用，结果和 Prettier 冲突，保存时来回打架。关键在配置分工：
-
ESLint只负责逻辑与规范：比如no-console、no-unused-vars、eqeqeq -
Prettier只负责排版：缩进、换行、引号、括号位置、逗号风格 - 在
.eslintrc.js中必须加extends: ['prettier']，关掉所有和排版相关的 ESLint 规则 - VS Code 设置里
editor.defaultFormatter必须是 Prettier，eslint.validate则只声明语言类型，不干预格式
真正难的不是装插件，而是让 Prettier 的规则落地到每个成员的编辑器里——.prettierrc 文件必须进 Git，formatOnSave 必须统一开启，否则一个人格式化，其他人保存就 revert 掉一半。协作环境下，格式不是审美问题，是协作契约。
