Prettier 3.9：用解析器重排代码的固执格式化工具，值不值得引入

它解决的问题：代码风格争论的终结者

Prettier 解决的是团队协作中一个具体而琐碎的问题：代码风格不一致。每个开发者都有自己的缩进习惯、换行偏好、引号选择。代码评审中经常出现关于格式的 nit-picky 评论，这些评论消耗注意力，却与逻辑无关。Prettier 的做法是彻底取消这些讨论。它解析代码，然后按自己的一套规则重新打印，规则是固定的，不提供太多配置选项。它的定位是 opinionated，也就是固执己见。你接受它的风格，或者不用它。它面向的是任何使用 JavaScript、TypeScript、CSS、HTML、Markdown 等语言的开发者，尤其是团队协作场景。个人开发者也可以用它来避免自己反复调整格式。

核心机制：解析后重印，而非查找替换

Prettier 与传统的查找替换式格式化器有本质区别。它先解析代码，生成抽象语法树，然后忽略原有格式，只根据 AST 和自身的打印规则重新生成代码。这个过程的关键参数是最大行宽。README 中的例子展示了这一点：一个包含多个长参数的函数调用，在输入时是一行，输出时被拆成多行，每个参数占一行，末尾加逗号。这不是简单的正则替换，而是基于对代码结构的理解。解析意味着它能处理嵌套表达式、模板字符串、注释位置等复杂情况。重印意味着输出是确定性的，同一段代码在任何环境下运行 Prettier，结果完全一致。这个机制也决定了它的局限：它不关心代码质量，只关心格式。它不会告诉你某个变量名不好，也不会检查是否存在未使用的导入。

接入方式：从编辑器到 CI 的完整路径

根据 README 和文档链接，Prettier 可以运行在三个层面。编辑器层面，它支持 on-save 自动格式化，这意味着你保存文件时，代码自动被重排。pre-commit 钩子层面，它可以在提交前运行，阻止不符合格式的代码进入版本库。CI 层面，它可以在持续集成中检查代码格式。安装方式上，文档提供了 Install 页面，通常是通过 npm 安装：`npm install --save-dev prettier`。CLI 命令包括 `prettier --write` 用于格式化文件，`prettier --check` 用于检查而不修改。配置方面，可以通过 `.prettierrc` 文件或 `prettier` 键在 `package.json` 中设置选项，比如 `printWidth` 控制最大行宽，`semi` 控制是否使用分号。API 层面，你可以通过 Node.js 调用 `prettier.format(source, options)` 来编程式格式化。文档还提供了一个 Playground 在线尝试。

真正局限：固执意味着不可定制

Prettier 的固执是一把双刃剑。它的设计哲学是少提供选项，这导致一些团队无法接受。比如，它默认使用双引号，但你可以通过 `singleQuote` 选项改为单引号。然而，对于更复杂的格式需求，比如是否在对象字面量中保留空行，或者如何对齐赋值操作符，Prettier 不提供选项。它的换行策略也偶尔产生奇怪的结果。当一行代码超过 `printWidth` 时，它会尝试拆分成多行，但拆分方式可能不符合你的直觉。例如，一个长的三元表达式可能被拆成多行，但嵌套的括号可能导致难以阅读的缩进。此外，Prettier 不支持自定义格式化规则。如果你需要某种特定的格式，比如强制在函数参数之间添加空格，Prettier 做不到。它只能做它定义好的那些事。对于需要高度定制格式的项目，Prettier 是错误工具。

与 ESLint 的替代关系：格式化与静态检查的边界

常有人将 Prettier 与 ESLint 对比，但两者解决的问题不同。ESLint 是静态检查工具，它检查代码质量，比如未使用的变量、可能的 bug、代码风格违规。Prettier 只负责格式。在 JavaScript 生态中，一个常见的组合是同时使用 ESLint 和 Prettier，用 ESLint 处理代码质量，用 Prettier 处理格式。但如果你只想要格式化，不想引入静态检查的复杂性，Prettier 是更轻量的选择。ESLint 的格式化规则需要手动配置，而且不同规则之间可能冲突。Prettier 则开箱即用，无需配置。反过来，如果你需要检查代码逻辑错误，Prettier 帮不了你。一个替代方案是使用 `eslint-plugin-prettier` 将 Prettier 作为 ESLint 的规则运行，但这样会增加耦合。另一个替代是使用 `dprint`，它用 Rust 编写，速度更快，但配置方式完全不同，且支持的语言范围不同。选择的关键在于你是否需要静态检查，以及你对格式化速度的要求。

维护与升级成本：版本更新频繁

从最近的发布记录看，Prettier 的维护非常活跃。3.9.6 在 2026 年 7 月 21 日发布，3.9.5 在 7 月 9 日，3.9.4 在 6 月 30 日。这意味着大约每两周就有一次更新。频繁的更新可能带来 bug 修复，但也可能引入格式变化。Prettier 的版本升级有时会改变默认的格式化行为，这会导致整个代码库的格式在升级后发生变化。对于大型项目，这可能是一个巨大的 diff，影响代码评审。因此，升级成本不容忽视。你需要在升级前运行 `prettier --check` 来评估影响，并准备在升级后重新格式化所有文件。许可证是 MIT，这意味着你可以自由使用、修改和分发，没有商业使用的限制。但这不是法律建议，具体问题需要咨询专业人士。

编辑结论

Prettier 适合那些厌倦了代码评审中关于缩进和换行争论的团队，尤其是以 JavaScript、TypeScript 或前端语言为主的仓库。它不适合需要自定义格式化规则的场景，也不适合那些希望格式化器同时做静态检查的团队。如果你决定采用，先验证两件事：一是你的编辑器插件和 pre-commit 钩子能否与 3.9.x 版本兼容，二是现有代码库中是否有大量长表达式或复杂三元表达式，因为 Prettier 的换行策略可能产生与预期不同的结果。最后，确认你的 CI 脚本中调用的命令是 `prettier --check` 而不是 `--list-different`，后者在旧版本中已被弃用。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes