Prettier正确配置指南：避免8大常见误区，实现团队代码格式化自动化

Prettier 在现代 Web 开发中几乎无处不在，但就像许多习以为常的工具一样，大多数人仅仅停留在“能用”的阶段，并未深入理解其最佳实践。仅仅安装并开启“保存时格式化”远远不够，如果没有正确的配置与集成，你很可能正在错误地使用它，这不仅关乎缩进或分号，更关乎工作流的效率和团队的协作一致性。

本文将揭示开发者最常踏入的八个 Prettier 使用误区，并提供清晰、可操作的解决方案，帮助你停止与格式化工具“对抗”，让它真正为团队服务。

1. 明确 Prettier 的职责：格式化，而非质量检查

首要的误解是认为 Prettier 能提升代码质量。事实并非如此，它不查找 Bug，也不优化业务逻辑。Prettier 的核心职责是强制实施一致的代码风格，你可以将其视为代码的自动排版机。它不改变代码的语义，只提升其可读性和可维护性。

示例对比：

// 未格式化
function greet(name){console.log('hello '+ name)}

// 经 Prettier 格式化后
function greet(name) {
  console.log("hello " + name);
}

两段代码功能完全相同，但后者无疑更清晰、易读。这就是 Prettier 提供的核心价值。

2. 误区一：Prettier 与 ESLint 规则冲突

如果你曾遭遇“ESLint 自动修复 → Prettier 重新格式化 → ESLint 再次报错”的无限循环，说明你的工具链正处于内战状态。根本原因在于 Prettier 和 ESLint 的规则存在重叠与冲突。

解决方案：明确分工。 让 Prettier 专注于代码格式化（如缩进、引号、行宽），而让 ESLint 专注于代码质量问题（如未使用变量、隐式全局声明）。通过专用集成包实现和平共处。

步骤：

1. 安装集成包：

   npm install --save-dev eslint-config-prettier eslint-plugin-prettier

2. 更新 ESLint 配置 (.eslintrc.js 或 .eslintrc.json)：

   {
     "extends": ["eslint:recommended", "plugin:prettier/recommended"],
     "plugins": ["prettier"],
     "rules": {
       "prettier/prettier": "error"
     }
   }

   配置后，eslint-config-prettier 会禁用所有与 Prettier 冲突的 ESLint 格式化规则，而 eslint-plugin-prettier 则将 Prettier 的格式化输出作为一条 ESLint 规则来报告。这样，你可以在一次检查中获得所有问题反馈，这是现代前端工程化工作流的关键一环。

3. 误区二：依赖全局默认配置

许多项目根本没有 .prettierrc 文件，这意味着整个团队在使用 Prettier 的全局默认配置，这几乎肯定与团队的实际编码风格不符。

解决方案： 在项目根目录创建明确的 .prettierrc 配置文件，并将其提交到版本库（如 Git）。这是团队代码风格统一的基石。

示例配置：

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "printWidth": 100,
  "trailingComma": "es5",
  "arrowParens": "always"
}

4. 误区三：忽略 .prettierignore 文件

Prettier 默认会尝试格式化项目目录下的所有文件，包括 node_modules、构建产物、压缩文件等，这会显著拖慢格式化速度并产生不必要的更改。

解决方案： 创建 .prettierignore 文件，排除无需格式化的目录和文件。

示例：

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

5. 误区四：仅使用 --write，忽视 --check 模式

prettier --write . 会直接格式化文件，而在 CI/CD 管道或提交前检查中，我们更需要的是“检查”而非“修改”。

解决方案： 利用 --check 模式。

npx prettier --check .

此命令会检查文件是否符合格式规范，并在不符合时报告错误而非直接修改。这非常适合集成到 Git Hooks 或持续集成流程中，确保代码库的格式一致性。

6. 误区五：编辑器未正确配置

即使项目安装了 Prettier，如果你的代码编辑器（如 VS Code）未将其设置为默认格式化工具，它也不会自动工作。

解决方案（VS Code）：
在项目或用户设置中确保以下配置：

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "prettier.requireConfig": true
}

• editor.defaultFormatter: 确保 Prettier 是格式化主力。
• editor.formatOnSave: 保存时自动格式化。
• prettier.requireConfig: 仅在项目有 .prettierrc 配置时才运行，避免意外格式化其他项目。

7. 误区六：忽视跨平台换行符问题

在 Windows (CRLF \r\n) 和 macOS/Linux (LF \n) 混合开发的团队中，换行符不一致会导致 Git  diff 出现大量无关修改。

解决方案：

1. 在 .prettierrc 中强制统一换行符：

   {
     "endOfLine": "lf"
   }

2. 在 .gitattributes 文件中进行全局设置，让 Git 统一处理：

   * text eol=lf

8. 误区七：手动运行，未实现自动化

将格式化步骤自动化是释放生产力的关键。手动运行命令是低效的。

解决方案：

1. 在 package.json 中定义脚本：

   "scripts": {
     "format": "prettier --write .",
     "check-format": "prettier --check ."
   }

2. 结合 Husky 和 lint-staged，实现提交前自动检查，这是运维/DevOps中“左移”质量关的经典实践。

   npm install --save-dev husky lint-staged

   在 package.json 中配置：

   {
     "lint-staged": {
       "*.{js,ts,jsx,tsx,css,md,json}": "prettier --check"
     }
   }

正确实践总结：构建自动化格式化工作流

1. 安装：npm install --save-dev prettier
2. 配置：创建团队约定的 .prettierrc 和 .prettierignore。
3. 集成：使用 eslint-config-prettier 与 ESLint 集成。
4. 配置编辑器：确保 VS Code 等编辑器设置正确。
5. 自动化：通过 npm scripts、Husky、lint-staged 实现提交前或 CI 中的自动化检查。

核心理念：Prettier 是团队契约

Prettier 不仅是一个工具，更是一份团队契约。它终结了关于“分号加不加”、“行宽多少”、“单引号还是双引号”的无休止争论，将团队的认知负担降至最低。其真正价值在于提升 Code Review 效率、减少风格争议、从而显著提高团队协作效能。正确配置并使用它，能让你的前端工程化流程更加顺畅和高效。