Prettier与ESLint在JS格式化中的区别及联合使用指南

一、区别剖析：Prettier 与 ESLint 的核心差异与设计哲学

初学者在搭建前端工程时，经常会对 Prettier 和 ESLint 产生混淆，甚至认为两者功能重叠只需保留其一。这种误解主要来源于 ESLint 早期的发展历史：在独立的现代格式化器普及前，ESLint 社区为了规范代码，内置了诸如单双引号、分号、缩进等大量外观规则。然而从设计初衷和工作底层机制审视，两者有着本质的边界划分。

1. 关注核心的差异：代码质量（Code Quality） vs 代码风格（Code Style）

代码规则在本质上可以清晰拆分为两个独立维度：

• 代码质量规则（ESLint 擅长）：此类规则关注代码的运行安全与逻辑合理性，例如 no-unused-vars（禁止未使用的变量）、no-undef（禁止使用未声明的变量）、eqeqeq（强制使用全等号 === 避免隐式转换）以及 no-unreachable（禁止无法执行的代码）。违反这类规则极易在运行时引发报错或隐藏深层缺陷。
• 代码风格规则（Prettier 擅长）：此类规则纯粹关乎代码的视觉呈现与阅读习惯，例如 semi（语句末尾是否加分号）、quotes（字符串采用单引号还是双引号）、tabWidth（缩进占用空格数）以及 printWidth（单行最大代码长度）。不论代码缩进是 2 个空格还是 4 个空格，JavaScript 引擎解释执行后的结果完全一致。

2. 底层运行机制的差异：遍历打补丁 vs 语法树重构打印

两者的实现机理直接决定了它们在处理复杂格式化时的表现差异：

ESLint 遵循“AST 匹配与局部替换”模式。它将源码解析为抽象语法树（AST）后，让各项规则去遍历寻找不合规的节点并抛出错误提示。虽然部分规则带有 --fix 能力，但其本质是针对局部代码切片进行字符串打补丁，缺乏对整体上下文排版的全局掌控能力。例如当一行代码过长时，ESLint 很难自动计算出包含深层解构、三元表达式和函数参数的最佳断行折行版式。

Prettier 则采用了“解析 AST 并彻底重新打印”的工作模式。Prettier 会解析代码并生成 AST 树，随后直接丢弃开发者书写的所有原始空格、空行与排版格式。它根据团队设定的行宽阈值（默认 80 字符）和算法模型，自顶向下以绝对确定的规则重新生成整份代码。这种机制让 Prettier 能够处理极其复杂的嵌套对象与链式调用，同时消除了“每个人保存格式各有微小差异”的顽疾。

二、原理深潜：格式化冲突产生的根源与现代协同方案

既然两者各有所长，为什么在同一个项目中往往会出现冲突？

冲突的根源在于规则重叠区。当项目既启用了 ESLint 的格式化规则（例如继承了 eslint:recommended 或 airbnb-base 中的引号规则 quotes: ["error", "double"]），又在 Prettier 中配置了 "singleQuote": true 时，两位“管家”对同一行代码的外观提出了截然相反的要求。在保存文件时，Prettier 刚将其格式化为单引号，ESLint 语言服务随即产生红色波浪线报错；若开启了 ESLint 保存修复，编辑器就会在两者之间高频闪烁、反复横跳，甚至出现保存死锁。

1. 历史方案的教训：为什么不推荐 eslint-plugin-prettier

在早期解决方案中，社区曾流行 eslint-plugin-prettier。它的运作原理是把 Prettier 包装成 ESLint 的一条内部检查规则，让 ESLint 在执行时内部调用 Prettier 比对源码差异，并将排版不一致转化为 ESLint 的 Error 抛出。

这种做法在现代开发体验中暴露了明显缺陷：

• 编辑器红线过载：编写代码过程中，每多打一个空格或少换一行，整个屏幕都会被密密麻麻的红色报错下划线覆盖，严重干扰逻辑思考。
• 显著的性能损耗：在保存或输入时频繁唤起完整的 Prettier AST 差异计算，会给 ESLint 语言服务带来成倍的内存与 CPU 负载，在大型单体仓库中尤为卡顿。
• 混淆问题严重性：将“行尾缺少空格”这种无关痛痒的排版问题，与“变量未定义可能导致崩溃”的严重代码质量问题赋予相同的 Error 级别，降低了代码审查的敏锐度。

2. 现代工业级方案：使用 eslint-config-prettier 进行“规则消音”

现代标准方案推崇“职责解耦”：通过 eslint-config-prettier，把 ESLint 中所有与代码排版有关的规则直接关闭（设为 "off"）。

在该方案下，ESLint 放弃管理引号、分号、换行和空格，只保留纯粹的代码逻辑诊断。代码排版完全由 Prettier 独占负责。由于没有了重叠仲裁者，开发者的编辑与保存链路畅通无阻。

三、联合使用实操指南：四步落地最佳配置

以下按照标准工程流程，说明如何在项目中完整落地 Prettier 与 ESLint 的协同配置。配置同时兼顾当前最新的 ESLint 9+ Flat Config（扁平配置）与经典版本（Legacy Config）。

步骤一：安装核心依赖

在项目根目录执行以下命令，将 Prettier、ESLint 以及消音配置库安装到开发依赖中。注意：无需安装 eslint-plugin-prettier。

# 使用 npm
npm install --save-dev eslint prettier eslint-config-prettier

# 或使用 pnpm
pnpm add -D eslint prettier eslint-config-prettier

# 或使用 yarn
yarn add -D eslint prettier eslint-config-prettier

步骤二：配置 ESLint 规避冲突规则

根据项目当前使用的 ESLint 配置文件格式，在配置末尾引入 eslint-config-prettier。

场景 A：现代 ESLint 9+ 扁平配置（eslint.config.js / eslint.config.mjs）

在扁平配置中，配置项以数组形式导出。只需将 eslint-config-prettier 导出的对象放入数组的最后一位即可：

import js from "@eslint/js";
import eslintConfigPrettier from "eslint-config-prettier";

export default [
  // 1. 基础推荐配置或语言解析规则
  js.configs.recommended,

  // 2. 自定义业务与质量规则
  {
    rules: {
      "no-unused-vars": "warn",
      "no-console": "off",
      "eqeqeq": ["error", "always"]
    }
  },

  // 3. 核心：必须放置在数组末尾，用于覆盖并关闭前面所有冲突的排版规则
  eslintConfigPrettier
];

场景 B：传统经典配置（.eslintrc.cjs / .eslintrc.json）

如果是使用 ESLint 8 或老旧脚手架的项目，在 extends 数组的最后一项添加 "prettier"：

module.exports = {
  env: {
    browser: true,
    es2021: true,
    node: true
  },
  extends: [
    "eslint:recommended",
    // 其他扩展规则，例如 "plugin:react/recommended" 等
    
    // 核心：必须写在 extends 数组的最后一项
    "prettier"
  ],
  rules: {
    "no-unused-vars": "warn"
  }
};

步骤三：编写 Prettier 风格基准配置

在项目根目录创建 .prettierrc.json 文件，固化团队的代码排版偏好：

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "quoteProps": "as-needed",
  "jsxSingleQuote": false,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

同时在根目录创建 .prettierignore 文件，排除不需要格式化的编译生成物与依赖文件：

node_modules/
dist/
build/
coverage/
*.min.js
package-lock.json
pnpm-lock.yaml

步骤四：配置 VS Code 实现保存无感自动格式化

为了保证团队成员在不同机器上行为完全一致，应将编辑器配置纳入版本控制。在项目根目录下创建 .vscode/settings.json：

{
  // 1. 设置全部文件默认格式化工具为 Prettier 扩展
  "editor.defaultFormatter": "esbenp.prettier-vscode",

  // 2. 开启保存时自动格式化
  "editor.formatOnSave": true,

  // 3. 针对 JavaScript / TypeScript 明确指定格式化器
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },

  // 4. 保存时联动执行 ESLint 代码动作（仅自动修复逻辑质量问题）
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  },

  // 5. 确保 ESLint 校验对应的语言类型
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ]
}

建议团队成员统一在 VS Code 中安装官方推荐的两个扩展：

1. Prettier - Code formatter (esbenp.prettier-vscode)
2. ESLint (dbaeumer.vscode-eslint)

四、结果验证与常见陷阱排查

1. 结果验证方法

完成上述配置后，通过以下三步验证整套机制是否健康运行：

• CLI 冲突检测：执行 npx eslint-config-prettier path/to/yourFile.js。该工具是 eslint-config-prettier 自带的辅助 CLI，它会扫描指定文件中是否存在已被开启但与 Prettier 冲突的 ESLint 规则。若无冲突，终端将提示 No rules that are unnecessary or conflict with Prettier were found.。
• 编辑器保存交互验证：在任意 JS 文件中故意写一行杂乱的代码（例如双引号且混杂多余空格：const greeting = "hello world" ;）。按下保存快捷键，观察代码是否在毫秒级自动被 Prettier 重写为干净的单引号且规范缩进，且 ESLint 没有抛出任何波浪线警告。
• 质量拦截验证：在文件中写一行未使用的变量（例如 const unusedValue = 100;）。保存后观察该变量是否依然保留黄色或红色下划线，证明 ESLint 质量检查工作完全正常。

2. 常见问题排查

五、总结与团队协作最佳实践

现代前端团队的高效开发，依赖于清晰透明的工具分工流水线。将 Prettier 与 ESLint 正确结合，不仅能终结团队在代码审查（Code Review）中针对分号与缩进的琐碎扯皮，还能构建起从开发到发布的纵深防御网络。