跳到正文

Biome 能取代 ESLint 和 Prettier 吗？

阅读约14分钟
前端JavaScript

这篇文章想聊聊一款名为 Biome 的工具。

我所在的团队成员使用 WebStorm、VSCode 等不同的 IDE，因此在维持统一的代码风格方面遇到了不少困难。不仅要为每种 IDE 分别管理配置文件，非常麻烦，代码评审中也经常因为格式差异而出现与逻辑无关的意见。

在这种情况下，ESLint 与格式化相关的规则被标记为 Deprecated，我们不得不寻找新的替代方案。Prettier + ESLint 组合需要额外配置来避免工具间的冲突，而 @stylistic/eslint-plugin-ts 当时还处于社区发展的早期阶段，稳定性尚未得到充分验证。就在这时，我们开始关注 Biome。

那么，Biome 究竟是一款什么样的工具？它真的能取代 ESLint 和 Prettier 吗？

Biome 是什么？

Biome 是面向 Web 项目的一体化（All-in-One）工具链。它通过一款工具统一提供 JavaScript、TypeScript、JSX、CSS、JSON、GraphQL 等代码的格式化与 lint 功能。其核心理念，就是用单个二进制程序承担 ESLint 和 Prettier 过去各自负责的工作。

Biome 的前身是 Rome。Rome Tools Inc. 在 2021 年获得 450 万美元风险投资后雄心勃勃地起步，但到了 2023 年年中，公司解雇了全部员工，代码仓库也被归档。随后，核心贡献者 fork 了该项目，并于 2023 年 8 月以 Biome 的名义重新出发。它摆脱了 Rome 时期“承诺过多、交付不足”的形象，通过实用且持续的 release 逐步建立起信任。

它最大的特点是采用 Rust 编写。至于这会带来怎样的性能差异，后文会详细说明。

为什么要使用 Biome？

选择 Biome 的理由主要可以归纳为三点。

一款工具就能同时处理格式化与 lint。 使用 ESLint + Prettier 组合时，为避免两款工具的规则冲突，需要添加 eslint-config-prettier 等额外配置。Biome 从根本上消除了这种复杂性。

性能非常出色。 根据官方 benchmark，它的速度约为 Prettier 的 25 倍、ESLint 的 15 倍。后文会通过直接对比来看看这些数字在实际中意味着什么。

Biome 官网的格式化速度对比：2,104 个文件共 171,127 行，Biome 0.41 秒，Prettier 14.35 秒，约快 35 倍

与现有工具兼容。 Biome 与 Prettier 的格式化兼容度约为 97%，并内置了 ESLint 的主要规则。eslint-plugin-react-hooks、eslint-plugin-jsx-a11y 等常用插件的规则也已集成，因此迁移负担相对较小。

如何使用？

Biome 的配置相当简单。官方文档中有清晰的说明，可以参考。

首先安装 Biome。

npm install --save-dev --save-exact @biomejs/biome

然后生成配置文件。

npx @biomejs/biome init

这会生成 biome.json 文件。在其中定义团队的格式化与 lint 规则即可。

还需要安装 IDE 扩展。使用 VSCode 时请安装 VSCode Biome；使用 WebStorm 时请安装 WebStorm Biome 插件。

最后，在 VSCode 的 settings.json 中添加以下配置，即可在保存时自动执行格式化和 lint。

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

直接比较一下

仅仅说速度快很难有直观感受，因此我在同一个项目中直接比较了 Biome 和 ESLint + Prettier。左侧是 Biome，右侧是 ESLint + Prettier。

Vite 项目的本地运行时间

使用 Biome 的 Vite 开发服务器启动结果，506 毫秒就绪 使用 ESLint 与 Prettier 的 Vite 开发服务器启动结果，630 毫秒就绪

Biome 为 506ms，ESLint + Prettier 为 630ms，运行时间快了约 20%。

Vite 项目的构建时间

使用 Biome 的 Vite 构建结果：117.13 秒 使用 ESLint 与 Prettier 的 Vite 构建结果：131.48 秒

Biome 为 117.13s，ESLint + Prettier 为 131.48s，构建时间快了约 10%。

Lint 任务

Biome 的 lint 执行结果：0.79 秒，CPU 0.470 秒 ESLint 的 lint 执行结果：16.32 秒，CPU 8.600 秒

差距最大的是 lint 任务。Biome 为 0.79s（CPU 0.470s），ESLint 为 16.32s（CPU 8.600s），Biome 的性能大约快了 20 倍。CPU 使用效率也高得多。

这种差异在开发环境中已经很明显，而在 CI/CD pipeline 中检查数百个文件时，差距会进一步扩大。Biome 无需通过 npm 安装即可直接运行二进制程序，因此还能节省 CI 的冷启动时间。

托着下巴陷入沉思的派大星角色

嗯……（到这个程度，反而更难找到不用它的理由了。）

为什么这么快？

“因为用 Rust 开发，所以速度快”这句话没错，但仅凭这一点还不足以完整解释。下面来看看造就 Biome 性能优势的具体技术因素。

Rust 的底层性能

10、100、300 并发连接下的平均 CPU 使用率对比：Node.js 稳定在 89~91%，Rust 为 145~206%，用上了多个核心 相同条件下的平均内存占用对比：Node.js 为 64~89MB，Rust 为 6~14MB

Biome 使用系统编程语言 Rust 编写。Rust 追求零成本抽象（Zero-cost Abstraction），即使使用高层抽象，也能达到与手动优化的底层代码相同的性能。此外，它不依赖垃圾回收器（GC），而是通过所有权（Ownership）系统管理内存，因此不会产生 GC 带来的 runtime overhead。

相比之下，ESLint 和 Prettier 使用 JavaScript 编写，运行在 Node.js runtime 上。尽管 V8 引擎的 JIT（Just-In-Time）编译会优化 JavaScript，但仍无法完全避开解释型语言的根本限制和垃圾回收成本。

单次解析架构

Biome 使用一个解析器（Parser）对代码进行一次解析，生成 AST（Abstract Syntax Tree，抽象语法树），并在格式化和 lint 时复用这棵 AST。

使用 ESLint + Prettier 组合时会发生什么？ESLint 先解析代码、生成 AST 并执行 lint；随后 Prettier 再次解析同一份代码，生成另一棵 AST 并执行格式化。也就是说，同一个文件会被解析两次。Biome 的单次解析架构从根本上消除了这种重复。

原生并行处理

同步与异步处理对比图：同步是请求与响应交替，异步则连续发出请求、稍后接收响应

Biome 利用 Rust 的并发模型，在多个线程中并行处理文件。它将任务拆分为较小的单元，并通过 work-stealing scheduler 在各线程间高效分配负载。Rust 的所有权系统会在编译阶段从根本上阻止数据竞争（Data Race），因此 runtime 的同步成本也能降到最低。

Node.js 默认采用基于事件循环的单线程模型。虽然可以使用 Worker Threads 实现并行处理，但线程创建和消息传递会带来额外 overhead。Biome 直接使用操作系统级的原生线程，因此能在没有这类 overhead 的情况下充分利用 CPU 核心。

内存高效的 AST 处理

语法树示例：左边是一元运算符 -1，右边是二元运算符 1 + 2，用运算符节点和整数节点表示

Biome 使用 CST（Concrete Syntax Tree，具体语法树）。根据 Biome 官方架构文档，这棵 CST 基于 rowan 库的内部 fork 实现了 Green/Red Tree 模式，能够保留原始代码中的全部信息，包括注释和空白。Rowan 的 Arena 风格内存分配将节点放在连续的内存区域中，从而提升 CPU 缓存局部性（Cache Locality），并尽量减少不必要的对象分配。

JavaScript 基于对象的 AST 处理方式会让每个节点都成为独立的 heap 对象，导致内存分散，并增大 GC 压力。Biome 的方式可以使用更少的内存实现更快的树遍历。

那么，应该引入 Biome 吗？

Biome 的性能和便利性显然很有吸引力。不过，我并不认为所有项目都应该无条件引入它。下面来看看几个实际需要考虑的因素。

适合使用 Biome 的情况

  • 维护大型代码库，构建和 lint 性能非常重要
  • 希望缩短 CI/CD pipeline 中的代码检查时间
  • 已经厌倦 ESLint + Prettier 配置的复杂性
  • 正在启动新项目，希望采用简洁的工具配置

我的团队也在维护一个大型项目，CI pipeline 中的 lint 耗时很长，开发者也苦于缓慢的 lint 速度，因此最终决定引入 Biome。

需要注意的事项

最大的限制是插件生态。 ESLint 拥有数千个社区插件，而 Biome 主要围绕内置规则运行。它已内置 eslint-plugin-react、eslint-plugin-react-hooks、eslint-plugin-jsx-a11y、eslint-plugin-unicorn、typescript-eslint 等主流插件的相当一部分规则，但并非每个插件的所有规则都已完成移植。Biome v2 已宣布将引入基于 GritQL 的插件系统，不过目前仍处于实验阶段。如果项目必须依赖 @next/eslint-plugin-next、eslint-plugin-angular 等框架专用规则，就需要谨慎考虑迁移。

还需要确认语言支持范围。 JavaScript、TypeScript、JSX、CSS、JSON、GraphQL 均已获得稳定支持，但 Vue 和 Svelte 的 SFC（Single File Component）文件目前只对 <script> 块提供部分支持。HTML、YAML 和 Markdown 尚未得到支持。

也不能忘记 ESLint 本身还在不断发展。 ESLint v9（2024 年 4 月）引入的 Flat Config（eslint.config.js）大幅简化了原有 .eslintrc 方式的复杂性。此外，它还分别在 2024 年 10 月和 2025 年 2 月发布 @eslint/json 与 @eslint/css，将 lint 范围扩展到 JavaScript 以外的语言。ESLint Stylistic（@stylistic/eslint-plugin）项目则提供了不使用 Prettier、仅靠 ESLint 完成格式化的方案。随着 ESLint 生态的演进，Biome 的“一体化”优势正在一定程度上被削弱。

此外，也需要记住 Rome 转变为 Biome 的历史。Rome 被归档时给现有用户造成的不便，说明选择工具时项目的可持续性有多么重要。幸运的是，Biome 通过 OpenCollective 和 GitHub Sponsors 获得资金支持，并保持着稳定的 release 周期。

npm trends 一年的每周下载量：eslint 与 prettier 在三千万到五千万之间，biome 几乎贴着坐标轴底部

从 npm trends 来看，Biome 每周约 690 万次的下载量与 ESLint 约 1.2 亿次、Prettier 约 8200 万次相比，仍有很大差距。不过，Biome 的增长速度值得关注。仅仅一年多的时间里，其周下载量便增长到原来的三至四倍以上，尤其是在新项目中的采用率显著上升。

写在最后

对于 Biome 能否完全取代 ESLint 和 Prettier 这个问题，我的回答是：“目前还不能，但它已经是非常有力的替代方案。”

它的性能非常出色，配置简洁，开发速度也很快。不过，插件生态尚不成熟，而且对部分语言的支持有限，这些问题可能会因项目而异，成为实际障碍。最好仔细评估项目的技术栈与团队需求，再决定是否引入。

有一点可以确定：前端工具生态正在朝着“更快、更简洁、更集成”的方向发展。不可否认，Biome 正站在这股潮流的前沿。它无疑是一款值得期待未来发展的工具。

评论