Prettier 负责代码格式统一，ESLint 专注逻辑错误与质量检查；二者分工明确、互补协作，通过 eslint-config-prettier 避免冲突，实现提交前自动检查与格式化。
直接用 Prettier 格式化代码，用 ESLint 检查逻辑和潜在错误——两者分工明确，配合使用效果最好。
Prettier 是代码“美容师”
Prettier 只做一件事：统一代码风格。它自动处理缩进、引号、括号换行、分号、逗号位置等视觉层面的格式问题，不关心代码是否能运行或有没有 bug。
- 开箱即用，配置极少（比如
singleQuote: true或semi: false） - 不接受“风格争论”，强制统一输出，团队协作时省去大量格式讨论
- 支持 JavaScript、TypeScript、CSS、JSON、Markdown 等多种文件类型
- 常集成到编辑器（如 VS Code）中，保存时自动格式化
ESLint 是代码“质检员”
ESLint 关注的是代码质量与规范。它通过规则检测潜在错误（如变量未定义、死代码）、安全风险（如 eval 使用）、可维护性问题（如过深嵌套），也支持自定义风格规则（但不推荐和 Prettier 冲突）。
- 规则可开关，例如
no-console、no-unused-vars、eqeqeq - 能配合 TypeScript 和 React 等生态插件（如
@typescript-eslint、eslint-plugin-react） - 建议关闭 ESLint 中与格式相关的规则（如
indent、quotes），交给 Prettier 处理 - 通常在提交前（git hook）或 CI 流程中运行，避免问题进入主干
怎么一起用才不打架？
核心原则：Prettier 负责格式，ESLint 负责逻辑和质量。关键在于让 ESLint 忽略格式类规则，并把 Prettier 当作一个“可执行的格式化工具”来调用。
立即学习“Java免费学习笔记（深入）”；
- 安装
prettier和eslint-config-prettier（禁用所有与 Prettier 冲突的 ESLint 规则） - 在 ESLint 配置中加入
"extends": ["eslint:recommended", "prettier"] - 用
eslint --fix修复 ESLint 能修的问题（如删除未用变量），再用prettier --write统一格式 - 推荐搭配
lint-staged+husky，实现 git commit 前自动检查+格式化
一句话总结区别
Prettier 决定代码“长什么样”，ESLint 判断代码“对不对、好不好”。一个管外表，一个管内里；一个靠重写，一个靠分析；不冲突，只互补。
基本上就这些。
