Bun 在 10 月 22 日的 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，还是别的文件类型？