代码风格之争（缩进用空格还是 Tab？单引号还是双引号？要不要加分号？）几乎是每个团队都会遇到的消耗性话题。Prettier 的出现终结了这场无休止的争论——它是一个“有主见”的代码格式化工具，通过解析代码并按照统一规则重新输出，强制所有代码风格一致，让团队成员不必再为格式问题在 Code Review 中浪费时间。
为什么需要 Prettier
手动统一代码格式是不现实的。每个人的编码习惯不同，即使定好了 ESLint 的格式规则，仍然可能在一些细节上不一致。Prettier 的价值在于：
- 零配置即可用：默认规则已经覆盖了绝大多数场景，开箱即用。
- 不可协商的格式规则：Prettier 只提供少数可配置选项，团队不必纠结于“哪种写法更好”。
- 支持多种语言：JavaScript、TypeScript、JSX、CSS、HTML、JSON、Markdown 等，甚至可以通过插件扩展更多语言。
- 与编辑器深度集成：保存文件时自动格式化，开发者甚至不需要知道格式规则的存在。
快速上手
在项目中安装 Prettier：
npm install --save-dev prettier创建配置文件 .prettierrc，虽然可以不配置，但团队通常会根据自己的需求微调几个选项：
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "all",
"printWidth": 100
}semi：是否在语句末尾加分号，默认true。singleQuote：使用单引号代替双引号，默认false。tabWidth：缩进空格数，默认2。trailingComma：多行时尾随逗号，可选"none"/"es5"/"all"。printWidth：每行最大字符数，超过自动换行，默认80。
在 package.json 中添加格式化脚本：
"scripts": {
"format": "prettier --write \"src/**/*.{js,jsx,ts,tsx,json,css,md}\""
}运行 npm run format 即可一键格式化整个项目。对于不想被 Prettier 处理的文件，可以创建 .prettierignore 文件，语法与 .gitignore 相同。
与 ESLint 的配合
ESLint 负责代码质量（如语法错误、潜在 bug、最佳实践），Prettier 负责代码格式（如缩进、换行、引号风格）。两者职责不同，但会存在规则冲突。解决冲突的标准做法是：
- 使用
eslint-config-prettier关闭所有与 Prettier 冲突的 ESLint 格式规则。 - （可选）使用
eslint-plugin-prettier将 Prettier 作为 ESLint 的一条规则运行，这样在 ESLint 检查时就能同时发现格式问题。
安装依赖：
npm install --save-dev eslint-config-prettier eslint-plugin-prettier在 .eslintrc 中配置：
{
"extends": [
"eslint:recommended",
"plugin:prettier/recommended"
]
}plugin:prettier/recommended 做了两件事：应用 eslint-config-prettier 关闭冲突规则，并启用 eslint-plugin-prettier将 Prettier 规则作为 ESLint 规则运行。这样，执行 eslint --fix 就能同时完成代码质量和格式的修复。
编辑器自动格式化
手动运行命令不如让编辑器在保存时自动格式化来得自然。以 VS Code 为例：
- 安装 Prettier 扩展。
- 在 VSCode 设置中将 Prettier 设为默认格式化工具：
"editor.defaultFormatter": "esbenp.prettier-vscode"
- 开启保存时自动格式化：
"editor.formatOnSave": true
此后，每次保存文件时，Prettier 都会按照项目根目录下的配置自动格式化当前文件。团队成员即使不关心格式规则，编辑器也能保证输出一致的风格。
实际使用经验
- 配置文件统一：将
.prettierrc提交到版本控制，确保所有成员使用相同的配置。 - 结合 pre-commit 钩子：在代码提交前自动运行 Prettier，防止未格式化的代码进入仓库。这需要用到下一节介绍的 Husky 和 lint-staged。
- 不要过度定制：Prettier 的设计哲学是“少即是多”，配置项有限是刻意为之。接受它的“固执”，能节省团队大量争论的时间。
- 一次性全量格式化：如果正在将 Prettier 引入已有项目，建议单独用一次提交对整个项目做全量格式化，并告知团队成员，避免巨大的 diff 掩盖业务逻辑变更。
Prettier 不是一个可选工具，而是现代前端工程化的标配。它将代码格式规范化到“无需思考”的程度，让团队真正可以把精力聚焦在代码逻辑上。