ESLint 和 Prettier 必须协同工作，核心是禁用 ESLint 的格式类规则（如 semi、indent），由 Prettier 掌管格式化，ESLint 仅负责质量检查；需配置 eslint-config-prettier、VSCode 默认格式化器为 Prettier、项目根目录含 .prettierrc，并确保三者配置对齐。
ESLint 和 Prettier 必须协同工作，单独启用任一插件都会导致保存时代码反复变动或规则失效。
为什么 ESLint 保存时会“来回改”代码
这是最常被忽略的根源问题：ESLint 和 Prettier 各自执行格式化逻辑，但职责没划清。比如 semi 规则设为 ["error", "always"]，而 Prettier 默认删分号，编辑器保存一次触发 ESLint 修、再触发 Prettier 删，循环往复。
- 根本原因不是插件装错了，而是没禁用 ESLint 中所有与格式相关的规则
- 必须通过
eslint-config-prettier插件关闭 ESLint 的格式类规则（如quotes、indent、semi） - 确保
extends数组里"prettier"放在最后——顺序决定覆盖优先级 - 不要在
.eslintrc.js里手动重写已被prettier关闭的规则，否则会绕过协同机制
如何让 Prettier 真正接管格式，ESLint 只管质量
关键不在“谁更强大”，而在“谁说了算”。Prettier 必须拥有最终格式化权，ESLint 只负责报错和语义检查。
- VSCode 设置中，
"editor.defaultFormatter"必须设为"esbenp.prettier-vscode"，不能是 ESLint 扩展 -
"editor.formatOnSave"开启，但"editor.codeActionsOnSave"里只保留"source.fixAll.eslint"，不加source.fixAll全局项 - 项目根目录下必须有
.prettierrc文件（哪怕只写{}），否则 Prettier 用默认配置，可能和 ESLint 的prettier配置不一致 - 若用
eslint.config.js（新格式），需显式导入prettierConfig并合并，不能只靠extends: ["prettier"]
JavaScript Booster 这类重构插件能用，但别依赖它替代 ESLint
像 JavaScript Booster 提供的 Convert to const 或 Replace with template string 是交互式重构，不是静态检查。它不读取你的规则配置，也不参与保存流程。
- 它的操作是单次、手动触发的，适合快速演进代码，但无法保证团队成员都用、都记得用
- ESLint 的
no-var、prefer-const等规则才是强制兜底——只要代码不符合，就报错，CI 会卡住 - 两者可并存：Booster 用于开发中主动优化；ESLint + Prettier 用于防止低级疏漏流入仓库
- 注意 Booster 在 TypeScript 文件里支持有限，某些箭头函数转换可能破坏类型推导，得人工核对
真正难的不是配通，而是让每个新加入的成员在 clone 项目后，第一次打开文件就能得到一致反馈——这要求 .eslintrc.*、.prettierrc、VSCode 设置三者严格对齐，且不能依赖个人本地设置覆盖项目配置。
