保存即格式化：Prettier 与 ESLint 的分工与团队配置实践Format-on-Save: How Prettier and ESLint Divide the Work and a Team Config That Works

分工：一个管格式，一个管质量The division: one formats, the other quality-checks

很多人刚接触时会困惑：Prettier 和 ESLint 都能改代码，那不是重复了吗？其实它们的关注点完全不同。Prettier 是一个"有主见的"格式化工具，它只关心代码长什么样：缩进是 2 空格还是 4 空格、单引号还是双引号、行宽多少、尾随逗号要不要。它不关心代码写得对不对、有没有潜在 bug。Many people are confused at first: both Prettier and ESLint can modify code, so isn't that redundant? They actually focus on completely different things. Prettier is an "opinionated" formatter — it only cares about what the code looks like: 2-space or 4-space indentation, single or double quotes, line width, trailing commas. It doesn't care whether the code is correct or has potential bugs.

ESLint 则是一个静态分析工具，它关心代码的质量和正确性：有没有未使用的变量、`==` 是不是该用 `===`、有没有可能的空指针、React 的 hooks 依赖对不对。ESLint 也有一些格式化相关的规则（如 `quotes`、`semi`），但官方推荐把这些规则关掉，交给 Prettier 统一处理——否则两个工具对同一件事有不同意见，就会打架。ESLint is a static analysis tool — it cares about code quality and correctness: unused variables, whether `==` should be `===`, possible null references, whether React hooks dependencies are correct. ESLint also has some formatting-related rules (like `quotes`, `semi`), but the official recommendation is to turn those off and let Prettier handle them uniformly — otherwise the two tools disagree on the same thing and fight each other.

我团队的原则是：所有"纯外观"的决策全部让 Prettier 拍板，团队不讨论；ESLint 只负责"代码逻辑和可维护性"层面的规则。这样分工后，prettier 配置文件通常只有 5 行以内，ESLint 配置则聚焦在业务规则上。My team's principle: all "pure appearance" decisions are made by Prettier, no team discussion; ESLint only handles rules at the "code logic and maintainability" level. With this division, the Prettier config is usually under 5 lines, and the ESLint config focuses on business rules.

团队配置实战：.prettierrc + eslint-config-prettierTeam config in practice: .prettierrc + eslint-config-prettier

一套能跑起来的配置长这样。首先是 `.prettierrc`，我团队用的是：A working config looks like this. First, `.prettierrc` — my team uses:

这五个选项覆盖了 90% 的格式争议。`semi: false` 是我们团队的选择（不加行尾分号），如果你们团队习惯加分号，改成 `true` 就行——关键是统一，不是哪个更"正确"。These five options cover 90% of style debates. `semi: false` is our team's choice (no semicolons); if yours prefer semicolons, just set it to `true` — what matters is consistency, not which is "correct."

然后是 ESLint 配置。核心是安装 `eslint-config-prettier`，它会把所有和 Prettier 冲突的 ESLint 规则关掉。在 `.eslintrc` 里把 `prettier` 放在 `extends` 数组的最后（顺序很重要，后面的会覆盖前面的）：Then the ESLint config. The key is installing `eslint-config-prettier`, which disables all ESLint rules that conflict with Prettier. In `.eslintrc`, put `prettier` last in the `extends` array (order matters — later entries override earlier ones):

如果用 TypeScript，再加 `@typescript-eslint/recommended`。还可以装 `eslint-plugin-prettier`，把 Prettier 的格式检查作为 ESLint 的一条规则来跑，这样 `eslint --fix` 就能同时修格式和质量问题。但我更推荐的做法是：格式化交给编辑器的保存动作（Prettier），ESLint 只在提交前和 CI 里跑质量检查，职责更清晰。For TypeScript, add `@typescript-eslint/recommended`. You can also install `eslint-plugin-prettier` to run Prettier's formatting checks as an ESLint rule, so `eslint --fix` handles both formatting and quality. But my preferred approach is: let the editor's save action handle formatting (Prettier), and let ESLint only run quality checks at commit time and in CI — cleaner separation of concerns.

还要配 `.prettierignore` 和 `.eslintignore`，把 `node_modules`、构建产物、自动生成的文件排除掉，否则跑全量检查时会很慢甚至报错。Also configure `.prettierignore` and `.eslintignore` to exclude `node_modules`, build artifacts, and auto-generated files, otherwise a full check can be slow or even error out.

保存即格式化与 CI 卡点Format-on-save and the CI gate

光有配置文件不够，关键是让工具在正确的时机自动跑起来。第一层是编辑器的"保存即格式化"。VS Code 里装 Prettier 扩展后，在 `settings.json` 里加：Config files alone aren't enough — the key is making the tools run automatically at the right moments. The first layer is editor "format-on-save." In VS Code, after installing the Prettier extension, add to `settings.json`:

这样每次 Ctrl+S，Prettier 就自动把代码格式好，开发者根本不需要刻意去想格式问题。WebStorm/IDEA 系列也有对应的 Save Actions 插件或内置的 "Reformat on save" 选项。This way, every Ctrl+S triggers Prettier to format the code automatically — developers don't even need to think about style. WebStorm/IDEA have equivalent Save Actions plugins or built-in "Reformat on save" options.

第二层是提交前卡点。用 `husky` + `lint-staged`，在 `git commit` 前自动对暂存区的文件跑 Prettier 和 ESLint。这样即使有人关了编辑器的保存格式化，提交时也会被强制修正。配置大致是：The second layer is a pre-commit gate. Use `husky` + `lint-staged` to automatically run Prettier and ESLint on staged files before `git commit`. Even if someone disables editor format-on-save, commits are still force-corrected. The config looks roughly like:

第三层是 CI 卡点。在流水线里跑 `prettier --check .` 和 `eslint .`，任何格式或质量问题都让构建失败。这一层是最后的保险，防止前两层被绕过（比如有人用 `--no-verify` 强推）。三层叠加后，代码风格问题基本不可能流入主干。The third layer is the CI gate. Run `prettier --check .` and `eslint .` in the pipeline; any formatting or quality issue fails the build. This is the final insurance against the first two layers being bypassed (e.g., someone force-pushes with `--no-verify`). With all three layers, style issues basically cannot reach the main branch.

最后说一个常见误区：不要把 Prettier 的配置写得很复杂。Prettier 的设计哲学就是"少配置"，选项越少，团队争议越少。如果发现自己在 `.prettierrc` 里写了十几行，大概率是把 ESLint 该管的事混进来了。需要快速格式化一段代码或验证格式效果时，可以用本站的代码格式化工具，支持多种语言，粘贴即格式化，适合在不配环境的机器上临时用。One common misconception: don't over-complicate the Prettier config. Prettier's design philosophy is "minimal config" — fewer options mean fewer team debates. If you find yourself writing a dozen lines in `.prettierrc`, you're probably mixing in things ESLint should handle. For quickly formatting a snippet or verifying formatting effects, our code formatter supports multiple languages and formats on paste — handy on machines without a local dev setup.