Prettier负责代码格式化，ESLint负责代码质量校验，二者需明确分工、避免规则冲突。应禁用ESLint的格式类规则，保留逻辑检查规则，并通过合理配置实现保存时自动格式化与实时错误提示。
VSCode 中的代码格式化，核心是让 Prettier 负责“怎么排版”，ESLint 负责“写得对不对”，两者分工明确、配合得当才能真正提升开发体验。关键不是装插件，而是理清谁管什么、配置不打架。
明确角色：Prettier 做格式，ESLint 做校验
Prettier 是一个“无配置”倾向的格式化工具——它不关心你是否用了分号、箭头函数怎么写，只按自己规则统一输出；ESLint 则专注代码质量，比如变量未使用、潜在错误、风格建议等。如果让 ESLint 也去管缩进或换行，就容易和 Prettier 冲突。
- 关掉 ESLint 的格式类规则（如 indent、semi、quotes），推荐用
eslint-config-prettier一键禁用 - Prettier 不检查逻辑，所以必须保留 ESLint 的 no-unused-vars、no-undef 等规则
- 格式化触发时机：保存时自动执行（VSCode 设置
"editor.formatOnSave": true），但仅对 Prettier 生效；ESLint 的提示始终在编辑器底部/波浪线下实时显示
VSCode 插件与基础设置
装两个插件就够了：Prettier（官方）和ESLint（由 Dirk Baeumer 维护）。不需要其他“格式化整合”插件，避免多层封装导致行为不可控。
- 在 VSCode 设置中搜索
default formatter，设为 Prettier（针对 JavaScript/TypeScript 文件） - 确保
"editor.formatOnSave"开启，同时加上"editor.formatOnSaveMode": "file"防止部分格式化出错 - 若想保存时同时修复 ESLint 问题，可开启
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，但需确认 ESLint 配置里已启用fixable规则
项目级配置文件怎么写
根目录下放好三个文件，各司其职：
-
.prettierrc：只写真正要覆盖默认的项，比如{"semi": false, "singleQuote": true, "tabWidth": 2} -
.eslintrc.js：继承eslint:recommended+plugin:react/recommended（如用 React）+prettier（最后一条，确保它在 extends 最末尾） -
.eslintignore：排除node_modules、dist、build等无需检查的目录
注意：eslint-config-prettier 必须通过 npm 安装，并在 extends 中显式引入，否则它的关闭规则不会生效。
常见冲突与快速排查
格式化后又报 ESLint 错误？大概率是规则没关干净，或 Prettier 和 ESLint 解析器不一致。
- 运行
npx eslint --print-config ./src/index.js查看最终合并后的规则，确认格式类规则是否为off - 检查
parser是否统一：ESLint 配置里应设"parser": "@typescript-eslint/parser"（TS 项目），Prettier 无需配 parser - 如果保存后格式反复“弹跳”，关掉其他格式化插件（如 Beautify、JavaScript Standard Style），只留 Prettier + ESLint
基本上就这些。不复杂，但容易忽略角色边界——把格式交给 Prettier，把质量托付给 ESLint，它们就能安静合作，而不是互相覆盖。
