先说结论：如果你的项目属于下面三类，别迁，Prettier 接着用没问题。
【为什么突然都在讨论取代 Prettier】今年关注前端工具链的人，应该都听过这组数字：Biome 声称 lint 比 ESLint 快 100 倍、格式化比 Prettier 快几十倍，一个工具顶两个；Oxlint 周下载量已经突破千万级；Rolldown 出了 1.0，Rspack 已经 2.x，整个工具链都在被 Rust 重写。知乎烈焰之雨空间而 Prettier 这边，相对安静：最新大版本还是 3.x，更新频率不高，每次更新还可能微调格式规则——这也是为什么官方文档特意提醒，安装时要用 --save-exact 锁版本号。一边是快车道，一边是维护模式，难怪很多人动心。但动心是一回事，动手是另一回事。翻完最近的迁移复盘、官方文档和几篇唱反调的文章，我们发现迁移成本被系统性低估了。
【三类项目别急着迁】第一类，Tailwind 深度使用的项目。如果你靠 prettier-plugin-tailwindcss 自动排序 class 名，迁移基本等于自断双臂。Biome 有自己的插件体系，跑不了 Prettier 的插件，而 Tailwind 的类名排序插件目前只有 Prettier 版本。换了 Biome，类名排序就得回到手动。第二类，依赖 Prettier 社区插件的项目。Prettier 的护城河其实不是核心，而是插件生态：Vue 模板、XML、小程序 wxml、PHP、Java，都有对应插件。Biome 2.x 确实在扩展语言支持，但像 Vue SFC 这类非核心语法的支持仍有限。布依前端你可以先 grep 一下项目里用到的插件，超过两个，迁移基本等于重做一遍格式化层。第三类，ESLint 插件一大堆的存量项目。7 月有一篇迁移复盘很有代表性：1200 个 TS 文件、23 个 ESLint 插件、286 条规则，ESLint 全量跑一次 32 秒；换到 Rust 系工具确实降到秒级，但逐个对照插件清单，实际规则覆盖率只有 60~70%，eslint-plugin-vue、unicorn、自定义规则，要么没有对应，要么行为不一致。烈焰之雨空间更隐蔽的坑在于：同一条规则，新旧工具的边界行为不同，有时新工具不报错，不代表代码没问题，只是检查逻辑不一样。这种假阴性，在代码评审里几乎看不出来。那怎么办？那篇复盘给出的方案是分阶段：先在 CI 里加一层快速预检（比如 oxlint），ESLint 和 Prettier 原样保留；等生态成熟再考虑全量切换。对 20+ 插件的存量项目，作者的建议是：别硬来。
【"99% 兼容"的真相】流传最广的说法是：Biome 的 formatter 与 Prettier 兼容 99%，直接换，没问题。烈焰之雨空间这句话对一半。常规 TS/JS 代码，两者格式化结果确实高度一致——但真正让项目翻车的，是剩下的那 1%。边界格式差异：长三元、特殊注释、JSX 嵌套等角落情况，输出会不同，切换瞬间 git diff 直接爆炸，还得处理 .git-blame-ignore-revs 跳过 blame 这些后续。今日头条配置也不兼容：Prettier 的 printWidth、trailingComma，在 Biome 里是 lineWidth、trailingCommas，文件是 biome.json，迁移是重写，不是复制。另外 .editorconfig 的读取、prettier-ignore 注释这些行为，都要逐一重新验证。所以即便是"零风险"的格式化层替换，也要预留一次全量格式化加一个专门 PR 的成本。
【哪些项目真的适合迁】也别被吓退，Biome 确实适合一部分项目：纯 TS/JS 的新项目，没有历史包袱，直接上 Biome，一个工具搞定格式 + 检查，快。技术宅-洛狸存量项目里，ESLint 插件少于 10 个、没有自定义规则的，可以找一个周末评估迁移，收益看得见。如果只是受不了格式化速度，先把 formatter 单独换成 Biome，ESLint 原样保留，试两周。把决策浓缩成一句话：新项目直接上，存量项目看插件数——少于 10 个可以迁，多于 20 个等一等，中间的先双轨跑。
【值得继续关注的信号】如果你是"再等等"阵营，可以盯几个信号：Biome 对 Vue SFC 和 Prettier 插件兼容的进展——这是存量项目能否迁移的分水岭；Oxlint 的 formatter 进度——Oxc 项目明确在做格式化，一旦落地，格局又要变；Prettier 官方的下一步动作——是继续 3.x 小迭代，还是拿出主打性能的大版本；以及规则覆盖率数据——Biome/Oxlint 对常用插件的覆盖什么时候过 90%，迁移成本会明显下降。前端工匠
一句话收尾：Prettier 没有死，它只是从"唯一选项"变成了"选项之一"。对多数存量项目来说，今年真正该做的，不是换工具，而是把手头工具链的版本号锁住。
