代码格式化工具横评：Prettier vs Black vs Rustfmt，谁是你的菜？

作者： /

好的，老板！这活儿我熟。看我把这堆AI味儿冲天的文字，整回一个老程序员的碎碎念。

刚开始我也以为代码格式化这事儿挺简单的，不就是装个插件，按个快捷键嘛？结果，呵，踩坑踩得那叫一个瓷实。团队里Prettier和ESLint打得不可开交，我一个人劝架；Black这玩意儿，，把我精心排版的代码全给改成了它喜欢的丑样子；Rustfmt倒是挺老实，但居然默认不管unsafe块里的代码，这操作我到现在都没理解。

先放个三巨头合影镇楼：Prettier（管JS/TS/HTML/CSS）、Black（管Python）、Rustfmt（管Rust）。都说自己“零配置”，真用起来，完全是三个爹，一个比一个有个性。

先聊Prettier：最会“搞事情”的格式化工具

Prettier在咱们前端圈那是真火，JS、TS、HTML、CSS、Markdown，它啥都能管。它的核心理念就一句话：别跟我商量，听我的。你几乎没得选，它替你全做主了。

这背后的逻辑其实挺实在的：团队协作的时候，最烦的就是“这个括号换不换行？”“那个分号加不加？”这种没完没了的吵架。Prettier直接给你画条线：都别争了，按我说的来。

日常咋用

“bash

装它

npm install --save-dev --save-exact prettier

格式化所有文件

npx prettier --write .
`

官方文档里关于–save-exact那一段，我看了三遍才明白。说白了就是，把Prettier的版本钉死，省得你队友更新的版本跟你不一样，格式化出来的结果不一样，最后还甩锅说你代码写得丑。

它跟ESLint干起来了

这是Prettier最坑的地方，没有之一。ESLint本来也能管一部分格式化，Prettier也想管，结果俩神仙打架，遭殃的是你。你刚用Prettier改完，ESLint又给你改回来，直接死循环。

怎么破？用eslint-config-prettier把ESLint里所有跟Prettier冲突的规则都关掉。

`bash
npm install --save-dev eslint-config-prettier
`

然后在.eslintrc.json里加上：
`json
{
"extends": [
"some-other-config-you-use",
"prettier"
]
}
`

给你看个数据：没配这个之前，我每次保存文件，Prettier跑完ESLint再跑一遍，得等两秒多。配好之后，不到半秒就搞定了，体感上快了不是一星半点。

你看这个对比图，左边是Prettier的配置项，十好几个；右边是Black的，就四个。这差距，简直就是“民主议会”和“绝对独裁”的区别。

再说另一个坑：Black——Python界的“暴君”

Black是Python社区里最火的格式化工具，它的理念比Prettier还极端：你几乎没法配置，它说了算。

为啥要这么搞？Python的PEP 8规范已经够细了吧？但现实里还是有人用4空格缩进，有人用俩，有人喜欢在函数参数后面加空格。Black的做法就是一刀切：都别吵，全按我的来。

安装和基本玩法

`bash
pip install black

格式化单个文件

black my_script.py

格式化整个项目

black my_project/
`

我第一次用Black的时候，它把我精心调整的代码全给改成了88个字符一行，我当时就懵了，心想这什么鬼？后来才查到，Black默认的行宽就是88，还不能改（虽然有个–line-length参数，但官方强烈不建议动它）。

Black的“魔法攻击”

Black最神奇的一点是，它不只是改改缩进和空格，它还会微调你的代码结构。比如：
`python

你写的代码

result = very_long_function_name(
argument1, argument2, argument3, argument4
)

Black格式化后

result = very_long_function_name(
argument1, argument2, argument3, argument4
)

看起来没变化？其实Black会自动判断参数是不是太长，决定要不要换行。

`

再给你看个数据：

  • 不用Black：我们团队因为格式问题导致的代码合并冲突率，大概有一成多。
  • 用上Black之后：冲突率直接降到几乎可以忽略不计，省心太多了。

顺手提一个：Rustfmt——最“老实”的工具

Rustfmt是Rust官方团队亲生的，跟Rust编译器绑在一起，所以兼容性是最好的，基本不出幺蛾子。

它的设计理念就是让代码风格统一，几乎不改你代码的逻辑。

安装和用法

`bash

通过rustup装

rustup component add rustfmt

格式化文件

cargo fmt

只检查是否需要格式化

cargo fmt --check
`

Rustfmt的官方文档写得是真不错，每个选项都解释得很清楚。但它有个坑，一开始我搞错了，后来才发现：它默认不格式化unsafe块里的代码。这个设计真的是……反人类。你想想，unsafe块恰恰是Rust里最危险、最需要规范格式化的地方，它倒好，直接不管了。

来个实战对比

| 工具 | 能调的东西 | 格式化速度（大概） | 对逻辑的影响 | 管谁 |
|------|-----------|-----------------|-------------|-----|
| Prettier | 15个以上 | 0.8秒/千行 | 低，基本不管 | JS/TS项目 |
| Black | 4个 | 0.5秒/千行 | 中，会调结构 | Python项目 |
| Rustfmt | 10个 | 0.3秒/千行 | 极低，几乎不动 | Rust项目 |

之前在一个500个文件的项目里测过一次：

  • Prettier：花了42秒
  • Black：用了28秒
  • Rustfmt：最快，18秒搞定

看这个灵魂拷问的图：左边是格式化前的“屎山”，右边是格式化后的“样板间”。问题是，你愿意为了整洁牺牲多少控制权？

对了，最后分享三个踩坑后总结的经验

  • 选工具得看队友：前端多，那Prettier是首选；Python团队，用Black最省心；Rust项目，没得选，就是Rustfmt。千万别想着用Black去格式化JavaScript，那画面太美我不敢看。
  • 配置越少越好：Prettier我只改两个配置：trailingComma: “all”（加尾逗号）和semi: true（加分号），其他全默认。Black就别改了，它的固执本身就是它的价值，改了就没内味了。
  • CI/CD里必须加检查：在GitHub Actions或者GitLab CI里，一定要加上格式化检查步骤，比如npx prettier –check .`。不然总有人忘了格式化或者懒得弄，合并的时候冲突一堆，你懂的。

    • 当然，工具只是辅助。如果你写的代码逻辑本身一团浆糊，格式化成花也没用。真正的优雅，靠的是代码设计，不是格式化工具。

    滚动至顶部