大部分开发者用错了Prettier，这里有正确用法
Prettier在现代网页开发中就像咖啡机：人人都在用，但真正知道它怎么工作的人很少。
大多数开发者安装完Prettier，打开"保存时格式化"选项，然后就不管了。
但有个尴尬的事实：如果你只是安装了Prettier，从没配置过它，那你很可能在用错它。
这不是关于"用Tab还是空格缩进"的问题。真正重要的是理解Prettier如何融入你的工作流程，它怎么和ESLint配合，以及它如何影响团队的代码一致性。
读完这篇文章你会了解：
开发者最常犯的Prettier使用错误
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"打架"
如果你见过"自动修复 → 重新格式化 → 恢复 → 再次格式化"的无限循环，那你就掉进了工具冲突的陷阱。
这个问题通常发生在开发者同时启用Prettier和ESLint的格式化规则，导致两个工具争着控制代码格式。
要解决这个问题，必须让Prettier负责格式化，ESLint只负责规则检查。
正确集成方法：
第一步：安装Prettier和ESLint集成包
npm install --save-dev eslint-config-prettier eslint-plugin-prettier第二步：更新.eslintrc文件
{
"extends": ["eslint:recommended", "plugin:prettier/recommended"],
"plugins": ["prettier"],
"rules": {
"prettier/prettier": "error"
}
}现在ESLint会用Prettier的格式规则，专注于真正的问题（没用的变量、没定义的import等）。再也不会发生格式化工具之间的"拔河比赛"。
3. 第二大错误：只用默认配置
很多开发者甚至没有创建.prettierrc文件。这意味着他们在用Prettier的全局默认配置，而这很可能不符合团队的编码风格。
在项目根目录创建.prettierrc文件：
{
"semi": true,
"singleQuote": true,
"tabWidth": 2,
"printWidth": 100,
"trailingComma": "es5",
"arrowParens": "always"
}现在你的格式是明确的、可控制的、可预期的，团队成员打开项目也不会看到格式差异。
重要提醒：一定要把.prettierrc提交到Git。这是团队统一格式的基础。
4. 第三大错误：不用.prettierignore
很多开发者不知道：Prettier默认会格式化所有文件。包括构建产物、JSON配置、自动生成的文件，这些会明显拖慢格式化速度。
创建.prettierignore文件：
node_modules
dist
build
coverage
package-lock.json
.next这样Prettier就只会处理真正需要格式化的文件。
5. 第四大错误：忽略检查模式
Prettier有个很有用的功能是--check选项：
--write：直接格式化文件
--check：只检查文件是否符合格式
npx prettier --check .这个功能特别适合用在CI/CD或Git提交钩子里，可以防止没有格式化的代码进入代码仓库。
配合Husky和Lint-Staged使用：
效果是什么？每次提交代码时，Prettier会自动检查所有文件是否符合格式规范。
6. 第五大错误：没同步编辑器设置
如果你用VS Code，这点特别重要。即使安装了Prettier，如果它不是默认格式化工具，它也不会自动运行。
打开VS Code设置（JSON格式），添加：
{
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
"prettier.requireConfig": true
}这样可以确保：
只有Prettier负责格式化
只在有.prettierrc配置的项目中运行（避免误伤其他项目）
保存时自动格式化
7. 第六大错误：忽略换行符问题
这是跨Windows和macOS团队最隐蔽的"痛点"。不同系统用不同的换行符（CRLF vs LF），导致Git出现很多"莫名其妙"的修改记录。
在.prettierrc中添加：
{
"endOfLine": "lf"
}在.gitattributes中设置：
* text eol=lf从此Git不会再有莫名其妙的文件修改显示。
8. 第七大错误：手动运行格式化
如果你还在手动运行Prettier，那是在浪费时间。
在package.json中加入：
"scripts": {
"format": "prettier --write .",
"check-format": "prettier --check ."
}现在你可以运行：
npm run format # 格式化所有文件
npm run check-format # 只检查格式配合Husky的pre-commit钩子，你甚至不需要自己想着格式化这件事。
9. 第八大错误：把Prettier当成普通工具
Prettier从来不是一个小工具，它是一个团队约定。它代表团队对代码风格达成了一致，避免没完没了的讨论：
"要不要加分号？"
"这行要不要换行？"
"大括号前要不要空格？"
当Prettier被纳入开发流程，它就成为整个代码库的唯一格式标准。真正的价值不是更漂亮的代码，而是更快的代码审查、更少的争论、更高的协作效率。
10. 正确使用Prettier的方法（专业团队实践）
完整步骤：
第一步：安装Prettier
npm install --save-dev prettier第二步：创建.prettierrc
{
"singleQuote": true,
"semi": false,
"trailingComma": "all"
}第三步：创建.prettierignore
node_modules
dist
build第四步：集成ESLint
npm install --save-dev eslint-config-prettier eslint-plugin-prettier第五步：配置VS Code
{
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
}第六步：设置Git钩子
npm install --save-dev husky lint-staged第七步：在package.json中加入
{
"lint-staged": {
"*.{js,ts,jsx,tsx}": "prettier --check"
}
}这样你就建立了一个自动执行、不需要人工干预、被专业工程团队广泛采用的格式化体系。
实际项目配置示例
完整的package.json脚本部分：
{
"scripts": {
"dev": "vite",
"build": "vite build",
"preview": "vite preview",
"lint": "eslint . --ext .js,.jsx,.ts,.tsx",
"format": "prettier --write .",
"check-format": "prettier --check .",
"prepare": "husky install"
}
}完整的.prettierrc配置：
{
"printWidth": 80,
"tabWidth": 2,
"useTabs": false,
"semi": true,
"singleQuote": true,
"trailingComma": "es5",
"bracketSpacing": true,
"arrowParens": "always",
"endOfLine": "lf"
}总结
Prettier是最简单的前端工具之一，也是最容易被用错的工具之一。
如果你没有.prettierrc、.prettierignore和CI检查，那你就错过了它真正的价值：
彻底的格式一致性
自动化工作流程
减少思维负担
当你正确使用Prettier，它就不再只是"格式化工具"，而是开发文化的一部分。所以问题是：你真的在用对Prettier吗？
本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！