# Bun 1.4.4 自带了 bun fmt，说比 Prettier 快，团队格式化要不要迁？ **URL:** \ **Category:** 开发调优\ **Tags:** JavaScript, 前端开发, Node.js\ **Created:** [2026 年11 月 2 日 13:18 UTC](https://www.shiqidu.com/t/topic/1904 "2026-11-02T13:18:40Z")\ **Posts on this page:** 1\ **Page:** 1
作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\ 发布日期： [2026 年11 月 2 日 13:18 UTC](https://www.shiqidu.com/t/topic/1904/1 "2026-11-02T13:18:40Z")
Bun 在 10 月 22 日的 [v1.4.4 发布说明](https://bun.com/blog/bun-v1.4.4) 里，开头就提了内置的 `bun fmt`。官方自称是 Prettier-compatible 的格式化工具，能读现有的 Prettier 或 oxfmt 配置。速度数字也写在同一篇里。相对 oxfmt 大约快 3x 到 6x（他们自己的对比表）。相对 Prettier，在 Prettier 自己的仓库上 `bun fmt --check` 约 60 ms、Prettier 约 17 秒，文中算成大约 286 倍，其他几个开源项目写的是 234x 到 425x。这些都是官方自评和复现步骤，换到你们仓库只能当参考，不能当成承诺。博客索引页的摘要也是同一套说法：`bun fmt`，Prettier-compatible，相对 oxfmt 快 3x 到 6x。 ## 兼容性别理解成「和 Prettier 百分百一样」 博客用的措辞是 Prettier-compatible，同时单开一节写 **Where bun fmt intentionally differs from Prettier** 。有几类输入 Prettier 会改掉语义，`bun fmt` 选择保留原意（文中举了 CSS 转义、选择器、Handlebars 注释等例子）。CI 里他们跑 Prettier 3.9.9 自己的格式化测试，总表写的是 9731 个用例里 9648 个字节级一致，大约 99.1%，并不是 100%。还有一批语法提案或插件相关用例被跳过。要是有人保证「迁过去 diff 一定为零」，和官方自己的数字对不上。 语言覆盖面官方列得很长：JS/TS/JSX、CSS 系、HTML、Vue/Svelte/Angular、JSON 系、YAML/TOML、Markdown/MDX、GraphQL 等。缺插件的语言会回退到项目里已安装的 Prettier。不支持的插件会报错并跳过相关文件。配置方面，说明里写了会读 `.prettierrc*`、`prettier.config.*`、`package.json` 里的 `prettier` 字段、`.editorconfig`、`.prettierignore`，以及 oxfmt 的配置文件，也支持 `// prettier-ignore`。Tailwind、`package.json`、Svelte 相关能力官方写了内建支持，但仍建议用你们真实仓库跑一遍 `--check` 对照。`bun fmt --doctor` 可以看配置怎么被解读。`bun format` 仍然会跑你自己的 `format` 脚本，和 `bun fmt` 不是同一条命令。脚本名没改、人却以为已经切到内置格式化，这种乌龙很常见。 ## 迁不迁，成本多半不在命令本身 格式化工具换不换，通常卡在「全仓一致的那一天」而不是命令行好不好记。命令可以从 `prettier --write .` 换成 `bun fmt`，听起来一步就完。真正耗时间的通常是这几块： - 编辑器：保存时格式化绑的是哪条命令、哪家插件。有人本机还没装 Bun，CI 却先切了。 - CI：`--check` 失败码、缓存、只扫变更文件（官方提供了 `--staged` / `--changed`）要不要重写流水线。钩子里原来依赖 `lint-staged` 的，要不要改成 `--staged`。 - 和 ESLint 的边界：格式归格式，规则归规则。以前靠 Prettier 插件消掉的冲突，换工具后要重新对一次「谁管缩进、谁管 unused」。 - 存量 diff：即便配置大体兼容，intentional 差异和插件回退也会刷出一轮纯格式 PR，需要和业务变更错开，否则 code review 会被噪声淹没。 - 发布与镜像：构建镜像里有没有 Bun，版本有没有锁到带 `bun fmt` 的 1.4.x。只在开发机装了、流水线还是旧镜像，检查会和本地对不上。 如果团队已经在 Bun 工具链里，可以先在一个包或一个目录试 `bun fmt --check`，把输出和现有 Prettier 结果做字节对比，再决定要不要动默认分支。对照时把 Markdown、CSS、带 Tailwind class 的文件单独看一眼。官方兼容表里这几类最容易冒出 intentional 差异。还在用 Node 跑主构建、只是听说更快就全仓替换，迁移噪音可能大过收益。速度数字引用官方博客即可。自己压测另说，别把别人的 286x 写进对内 RFC 当验收标准。 会不会迁，取决于你们已经在不在用 Bun、能不能接受一轮格式噪音，以及官方兼容范围盖不盖得住仓库里的插件。先小范围对照，再谈默认分支。 你们试过 `bun fmt` 没有？和现有 Prettier 配置撞车的是插件、Markdown，还是别的文件类型？