Biome 2.5 评测：用 Rust 重写的前端工具链，能否取代 Prettier 与 ESLint？

一个工具，两个痛点

Web 项目维护中，格式化与代码检查通常是两套独立工具：Prettier 管格式，ESLint 管规则。它们各有配置，各有插件，各有性能瓶颈。Biome 的定位很直接：用 Rust 写一个工具链，把这两件事合到同一个二进制里。README 说它提供 formatter 和 linter，可通过 CLI 和 LSP 使用。它针对 JavaScript、TypeScript、JSX、JSON、CSS 和 GraphQL，覆盖了现代前端的主要语言。目标用户是那些厌倦了维护多套配置、希望减少构建链复杂度的团队。Biome 不要求 Node.js 也能运行，这对 CI 环境或非 Node 项目有实际意义。

从安装到运行：命令即配置

安装方式很常规：`npm install --save-dev --save-exact @biomejs/biome`。注意 `--save-exact`，这是官方建议，避免版本漂移。使用上，核心命令就几个：`npx @biomejs/biome format --write` 格式化，`npx @biomejs/biome lint --write` 执行 lint 并应用安全修复，`npx @biomejs/biome check --write` 同时跑格式化和 lint，`npx @biomejs/biome ci` 用于 CI 环境检查。这些命令直接对应常见工作流，没有复杂的子命令层级。README 强调“sane defaults and it doesn't require configuration”，即默认配置即可用，这对快速启动很友好。不过，这也意味着如果你需要调整规则，得去查文档，而不是靠直觉。

格式化兼容性：97% 意味着什么

README 宣称 Biome 的格式化器与 Prettier 有 97% 兼容性。这个数字来自一个挑战赛链接，具体测试方法未在 README 中展开。97% 听起来很高，但反过来看，每 100 个文件中可能有 3 个格式不同。对于追求 Prettier 严格一致性的团队，这 3% 可能是迁移的障碍。Biome 的定位是“快速”，它用 Rust 实现，理论上比 Node 版的 Prettier 快很多，但 README 没有给出具体基准数字。它没有声称 100% 兼容，这说明项目方清楚差异存在。如果你从 Prettier 迁移，建议先跑一次 `check --write`，看看实际差异是否可接受。

lint 规则：数量不等于覆盖

Biome 的 linter 宣称有超过 500 条规则，来源包括 ESLint、typescript-eslint 和其他。数量多，但关键问题是这些规则是否覆盖你项目实际使用的规则。ESLint 生态有大量插件，比如 React 的 `eslint-plugin-react` 或 Vue 的 `eslint-plugin-vue`，Biome 的 500 条规则未必涵盖所有插件。README 提到规则来自“other sources”，但没有具体列出哪些。这意味着如果你依赖特定插件规则，需要逐一核对。Biome 的输出是“detailed and contextualized diagnostics”，强调诊断信息丰富，帮助开发者理解问题。这是它的一个卖点，但实际体验需要 LSP 或 CLI 验证。

LSP 与编辑器集成：第一等公民

README 明确说 Biome 从设计之初就考虑编辑器内交互，提供一流的 LSP 支持。它有官方的 VS Code 扩展，并出现在 Open VSX 上，说明不仅限于微软商店。LSP 的意义在于实时反馈：你输入代码时，格式化和 lint 结果即时显示。这比每次跑 CLI 高效得多。但 LSP 的稳定性取决于解析器的错误恢复能力。README 提到“sophisticated parser that represents the source text in full fidelity and top-notch error recovery”，即解析器能保留源码原貌并具备错误恢复。这听起来不错，但“top-notch”是主观描述，实际体验需要测试。对于重度使用编辑器的开发者，LSP 是核心功能，值得先验证。

性能与并行：设计上的优势

Biome 用 Rust 编写，这带来两个直接优势：单二进制部署，无需 Node.js 环境；以及并行处理能力。README 说“Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelize work, caching, and configuration”。共享基础意味着格式化、lint、解析共用同一套代码，错误显示和缓存机制一致。并行化是 Rust 的强项，但 README 没有给出具体性能数据。对于大型代码库，性能是实际痛点，但你需要自己测量。Biome 的缓存机制可能减少重复工作，但细节未在 README 中说明。如果你关心性能，建议在真实项目上对比 `time npx biome check` 与现有工具链。

局限与替代方案

Biome 的一个明显局限是它试图统一工具，但生态成熟度不如 Prettier 和 ESLint。Prettier 有大量插件支持不同语言和框架，ESLint 有几乎无限的规则插件。Biome 的 97% 兼容性意味着它不是 drop-in 替代品。另一个问题是升级频率：从 2.5.9 到 2.5.11 仅隔十天，说明项目活跃，但也可能带来配置变更。替代方案是继续使用 Prettier 加 ESLint 的组合，它们各自成熟，但需要两套配置和两个运行器。或者选择其他 Rust 工具如 `dprint`，但 README 未提及。Biome 的替代不是另一个工具，而是“保持现状”的选项。如果你的项目已经稳定运行在 Prettier 和 ESLint 上，迁移成本可能高于收益。

许可证与维护成本

Biome 采用 MIT 或 Apache-2.0 双许可，README 明确写了，这对商业项目友好，没有 GPL 的传染性。维护成本方面，项目活跃，有企业赞助和核心贡献者，但 README 没有提到升级路径或迁移指南。由于是 Rust 编写，如果你需要修改内部行为，得懂 Rust，这比 JS 工具门槛高。但大多数用户只通过 CLI 或 LSP 使用，不需要碰 Rust。升级成本取决于你如何安装：npm 包方式可以指定精确版本，`--save-exact` 就是为此。频繁发布意味着你需要定期更新以获取修复，但也要测试新版本是否改变行为。没有长期支持版本的信息，所以需要自己控制升级节奏。

编辑结论

Biome 适合那些希望用单一工具替代 Prettier 加 ESLint 组合、且对性能敏感的前端团队，尤其是新项目或配置负担较重的旧项目。它不适合需要深度定制 lint 规则或依赖 Prettier 特定插件生态的团队，因为其 97% 兼容性意味着仍有 3% 的格式差异，且规则集虽大但未必覆盖所有 ESLint 插件。采用前应验证三点：一是用 `npx @biomejs/biome check --write` 在真实代码库上运行，检查格式差异是否可接受；二是确认所需 lint 规则在 500 多条中是否齐全；三是若使用编辑器，需测试 LSP 在你常用编辑器中的稳定性。Biome 的 Apache-2.0 或 MIT 双许可对商业项目友好，但升级频率高（2.5.9 到 2.5.11 仅隔十天），需要留意版本更新带来的配置变更。若你的项目深度依赖 Prettier 的插件或 ESLint 的自定义规则，Biome 可能不是直接替代品，而是一个需要权衡的迁移目标。

官方来源

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