Prettier 配置完全指南：统一代码风格的最佳实践
技术贝贝前端代码格式化神器：Prettier 配置实战指南
作为一名写了好几年前端的老兵，我早就受够了团队里各种奇奇怪怪的代码风格。有人喜欢分号结尾，有人坚决不用；有人缩进用 2 个空格，有人偏要 4 个。每次看别人写的代码，光是适应格式就头疼。后来我开始在项目里强制使用 Prettier，这玩意儿一上，代码风格瞬间统一，连争论都省了。Prettier 是一个「有主见」的代码格式化工具，它不让你配置太多细节，而是直接给你一套默认规则，你只需要接受或者放弃。这种「约定优于配置」的理念，反而让团队协作顺畅多了。尤其是在多人协作、频繁 Code Review 的项目里，Prettier 简直是救星。
环境准备
要在项目里用上 Prettier，首先得装 Node.js（建议 16+），然后初始化一个 npm 项目。如果你还没初始化，跑个 npm init -y 就行。接着安装 Prettier 本体，推荐作为开发依赖安装：
npm install --save-dev prettier另外，为了在编辑器里实时格式化，你还需要在 VS Code 里装官方插件「Prettier – Code formatter」。装完后记得在设置里把默认格式化工具设成 Prettier，不然可能还是用的 ESLint 或其他工具。我之前就因为没设默认，折腾了一下午才发现格式化根本没生效。
基础用法
最简单的用法就是直接运行 Prettier 命令。比如你想格式化整个 src 目录下的所有 JS 文件，可以这样写：
npx prettier --write src/**/*.js但更常见的做法是创建一个配置文件，这样团队成员都能用同一套规则。在项目根目录下新建一个 .prettierrc 文件（支持 JSON、YAML、JS 等格式，我习惯用 JSON）：
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"trailingComma": "es5",
"printWidth": 80
}这几个配置很常用：semi 决定是否加尾分号，singleQuote 强制用单引号，tabWidth 控制缩进宽度，trailingComma 在对象或数组末尾加逗号（方便 git diff），printWidth 是一行最大字符数。配完之后，你可以在 package.json 里加个脚本：
{
"scripts": {
"format": "prettier --write ."
}
}这样运行 npm run format 就能格式化整个项目（除了被忽略的文件）。别忘了配一个 .prettierignore 文件，把 node_modules、dist、build 这些目录排除掉：
node_modules
dist
build
*.min.js不然 Prettier 可能会去格式化压缩后的文件，那可就乱套了。
进阶技巧
实际项目中，光有 Prettier 还不够，往往要和 ESLint 配合使用。但这两个工具容易打架——ESLint 检查格式，Prettier 也格式化，结果互相覆盖。我踩过这个坑，最后发现最佳方案是让 ESLint 只管代码质量，Prettier 只管格式。具体做法是用 eslint-config-prettier 关掉 ESLint 中和 Prettier 冲突的规则。
先安装依赖：
npm install --save-dev eslint-config-prettier然后在 .eslintrc.js 的 extends 里加上它，而且必须放在最后：
module.exports = {
extends: [
'eslint:recommended',
'plugin:react/recommended',
'prettier' // 必须放最后
],
// 其他配置...
};这样 ESLint 就不会报那些格式相关的错误了。另外，你还可以在 VS Code 里设置保存时自动格式化。在 settings.json 中加入：
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode"
}不过要注意，如果项目里同时用了 ESLint，可能需要额外配置 editor.codeActionsOnSave 来先 fix ESLint 再格式化，否则顺序乱了还是会冲突。我现在的项目里就这么干：
{
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"editor.formatOnSave": true
}这样先让 ESLint 修复可自动修复的问题，再交给 Prettier 格式化，完美配合。
常见问题
1. 为什么保存时没有自动格式化？
首先检查 VS Code 是否安装了 Prettier 插件，并且是否设为默认格式化工具。其次看 workspace 设置里有没有覆盖全局设置。有时候项目根目录有 .vscode/settings.json，里面可能禁用了 formatOnSave。
2. Prettier 和 ESLint 冲突，保存后格式反复横跳？
这基本是因为没正确配置 eslint-config-prettier。确保它在 ESLint 的 extends 数组最后，而且没有手动开启那些格式规则。另外，确认 VS Code 的保存顺序：先 ESLint fix，再 Prettier 格式化。
3. 某些文件类型没被格式化？
Prettier 默认只支持主流语言。如果你在写 .vue、.svelte 或 .mdx 文件，需要额外安装对应插件，比如 @prettier/plugin-pug。或者在 .prettierrc 里显式指定 parser。
4. 团队成员格式化结果不一致？
大概率是有人没装 Prettier，或者用了不同版本。解决方法是在 package.json 里锁死 Prettier 版本，并通过 lint-staged + husky 在提交前强制格式化，确保进仓库的代码都是统一风格。
实践建议
在真实项目中，我强烈建议把 Prettier 配置和 Git Hooks 结合。用 husky + lint-staged，在每次 commit 之前自动格式化暂存区的文件。这样即使有人忘了开 formatOnSave，也不会污染代码库。配置起来也不难，装完 husky 和 lint-staged 后，在 package.json 里加一段：
{
"lint-staged": {
"*.{js,jsx,ts,tsx,json,css,scss,md}": "prettier --write"
}
}另外，不要试图在 Prettier 里配置太多细节。它的哲学就是「少即是多」，你越想自定义，越容易和团队其他工具冲突。接受它的默认规则，反而能省下大量争论时间。最后，记得在项目 README 里写清楚格式化规范，新成员一进来就知道该怎么配，避免重复踩坑。毕竟，我们的目标是写代码，不是调格式。
