17370845950

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 当作一个“可执行的格式化工具”来调用。

• 安装 prettier 和 eslint-config-prettier（禁用所有与 Prettier 冲突的 ESLint 规则）
• 在 ESLint 配置中加入 "extends": ["eslint:recommended", "prettier"]
• 用 eslint --fix 修复 ESLint 能修的问题（如删除未用变量），再用 prettier --write 统一格式
• 推荐搭配 lint-staged + husky，实现 git commit 前自动检查+格式化

一句话总结区别

Prettier 决定代码“长什么样”，ESLint 判断代码“对不对、好不好”。一个管外表，一个管内里；一个靠重写，一个靠分析；不冲突，只互补。

基本上就这些。