3、代码格式化利器：Prettier的安装与配置、与编辑器的集成、团队统一格式化策略

说实话，代码格式化这件事，我见过太多团队吵得不可开交了。

有人喜欢双引号，有人偏要单引号。有人觉得分号必须加，有人觉得不加更清爽。你想想看，每天Code Review的时候，一半时间都在争论这些鸡毛蒜皮的事，多浪费啊。

Prettier就是来解决这个问题的。它是个「固执己见」的格式化工具，说白了就是——你别跟我争，听我的就行。

3.1 为什么非得用Prettier？

我记得刚带团队那会儿，有个项目组因为缩进风格吵了整整两周。最后怎么解决的？我直接拍板：所有人必须用Prettier，格式化规则写进配置文件，谁也别想改。

Prettier的核心价值就三点：

• 统一风格：不管你怎么写，保存文件后自动变成团队统一的格式
• 消除争议：代码风格不再需要人工讨论，机器说了算
• 节省时间：开发者不用再手动调整缩进、空格、换行

3.2 安装Prettier

安装方式有两种，我个人建议用项目级安装，而不是全局安装。为什么？因为每个项目的格式化规则可能不一样，全局安装容易出问题。

方式一：项目级安装（推荐）

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

# 使用 yarn
yarn add --dev prettier

# 使用 pnpm
pnpm add --save-dev prettier

方式二：全局安装

npm install -g prettier

3.3 配置文件怎么写？

Prettier支持多种配置文件格式。我个人习惯用 .prettierrc，因为它最简洁，也最直观。

常见的配置项

配置项	默认值	说明
printWidth	80	每行最大字符数，超过则换行
tabWidth	2	缩进使用的空格数
useTabs	false	是否使用Tab缩进，建议用空格
semi	true	是否在语句末尾加分号
singleQuote	false	是否使用单引号
trailingComma	"es5"	多行时是否添加尾逗号
bracketSpacing	true	对象字面量中括号间是否加空格
arrowParens	"always"	箭头函数参数是否加括号

一个典型的配置文件

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

3.4 与编辑器集成

光有配置文件还不够，你得让编辑器在保存文件时自动调用Prettier。这才是真正的「无感格式化」。

VS Code集成

1. 安装插件：搜索「Prettier - Code formatter」并安装
2. 设置默认格式化器：在设置中搜索 editor.defaultFormatter，选择 esbenp.prettier-vscode
3. 开启保存时格式化：设置 editor.formatOnSave 为 true

// VS Code settings.json 配置示例
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

WebStorm集成

1. 打开设置 → Languages & Frameworks → JavaScript → Prettier
2. 选择Prettier包路径（通常是项目中的 node_modules/prettier）
3. 勾选「On save」自动格式化

3.5 团队统一格式化策略

工具装好了，配置写好了，怎么让整个团队都用起来？这才是真正的难点。

第一步：配置文件纳入版本控制

把 .prettierrc 和 .prettierignore 提交到Git仓库。这样每个成员拉取代码后，自动获得统一的格式化规则。

# .prettierignore 示例
node_modules
dist
build
coverage
*.min.js
*.map

第二步：集成到CI/CD流程

在CI中增加Prettier检查步骤，如果代码格式不符合规范，构建直接失败。

// package.json 中添加脚本
{
  "scripts": {
    "format": "prettier --write \"src/**/*.{js,ts,json,css,md}\"",
    "format:check": "prettier --check \"src/**/*.{js,ts,json,css,md}\""
  }
}

第三步：配合Git Hooks

使用 husky 和 lint-staged，在提交代码前自动格式化。

// 安装依赖
npm install --save-dev husky lint-staged

// package.json 配置
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,ts,json,css,md}": ["prettier --write", "git add"]
  }
}

3.6 避坑指南

嗯，这里要说说我踩过的几个坑，希望能帮你少走弯路。

• 不要和ESLint冲突：如果同时使用ESLint和Prettier，记得安装 eslint-config-prettier，关闭ESLint中与Prettier冲突的规则。
• 版本要统一：团队所有成员必须使用相同版本的Prettier。我曾经遇到过有人用2.0，有人用1.8，格式化结果不一样，排查了半天。
• 不要过度配置：Prettier的设计理念就是「少配置」。你改得越多，越容易出问题。我一般只改 printWidth、singleQuote、trailingComma 这三个。
• 大项目要分批格式化：如果项目已经运行了很久，代码风格不统一，不要一次性格式化所有文件。否则Git历史会变得一团糟。我建议分批处理，每次只格式化一个模块。

好了，这一章就到这里。下一章我们聊聊ESLint——那个真正帮你「写好代码」的工具。