Rust 编写的 JS/TS 一体化工具,单二进制替代 ESLint 和 Prettier,10000 文件 lint 仅需 0.8 秒(ESLint 45.2 秒),格式化仅 0.3 秒。
在一个典型的 TypeScript monorepo 中,仅 linting 就能消耗每次 CI 运行 45 秒,而这还是在 Prettier 还没上场之前。根据 dev.to 上 2026 年的 linting 对比报告,在 10000 个文件上运行 ESLint 需要 45.2 秒,而 Biome 完成同样的工作只需要 0.8 秒。用 Prettier 格式化同样数量的文件需要 12.1 秒;Biome 只需要 0.3 秒。
Biome 是一个单一的 Rust 二进制文件,用一个工具同时替换 ESLint 和 Prettier。没有独立的配置文件,没有需要串联的插件生态,也不需要等待 Node.js 启动一个 linting 进程。它可以格式化、linting,以及(越来越多地)做类型检查,覆盖 JavaScript、TypeScript、JSX、JSON、CSS 和 GraphQL。
本文涵盖 Biome 实际的工作原理、"56 倍更快"背后的真实基准数据、哪些公司已经在生产环境中运行它、它与 ESLint + Prettier 组合逐项功能的对比,以及迁移现有项目的具体步骤。
Biome 最初是 Rome 项目的一个分支,Rome 是 Meta 的 Sebastian McKenzie 在 2023 年放弃的项目。社区接手了它,重写了治理模型,并将其作为独立工具链发布。到 2026 年,它已经成为每个 JavaScript 团队最终都会问的一个问题的默认答案:为什么检查代码风格需要两个独立的工具、两份配置文件,以及一堆插件?
Biome 作为一个二进制文件发布。它有合理的默认配置,第一天就能零配置产生有用的输出,同时也支持通过 biome.json 文件为需要自定义规则的团队提供配置。在底层,它解析源文件一次,然后复用同一个 AST 来进行 linting 和格式化,这是它不需要像 ESLint 和 Prettier 那样为每个关注点启动独立 Node.js 进程的主要原因。
这个项目增长很快。根据其 GitHub 仓库数据,Biome 已获得 24400 颗星和 9790 次提交,根据 Programming Helper 的 2026 年汇总,其月下载量已突破 1500 万次。这种增长曲线正在迫使从 2015 年就开始运行 ESLint 的团队认真考虑切换。
这个标题数字——Biome 比 ESLint 快 56 倍——来自同一份 Programming Helper 分析,当你深入底层机制而不仅仅是看营销文案时,它是站得住脚的。
三个因素解释了大部分速度差距:
无 JavaScript 运行时开销。ESLint 和 Prettier 本身就是 JavaScript 程序,这意味着每次运行都要支付启动 Node、加载解释器以及 JIT 预热热路径的成本。Biome 是一个编译后的 Rust 二进制文件,可以即时启动。
一次解析,而非两次。ESLint 解析文件进行 linting;Prettier 再次解析它进行格式化。Biome 解析一次,两个操作都从同一棵树读取。
默认并行化。Biome 的 Rust 核心在多个线程上并行遍历项目文件,无需额外配置,而 ESLint 的插件架构使真正的并行执行难以改造。
上述 dev.to 基准测试是在一个拥有 10000 个文件的生产级代码库上直接测量的:
| 任务 | ESLint + Prettier | Biome | 加速比 |
|---|---|---|---|
| Lint 10000 个文件 | 45.2s | 0.8s | ~56x |
| 格式化 10000 个文件 | 12.1s | 0.3s | ~40x |
| 冷启动 | ~1-2s(Node 启动) | <50ms | ~20-40x |
对于一个在每个 Pull Request 上都运行 lint-and-format 检查的 CI 管道来说,这意味着检查在开发者还没滚回编辑器之前就完成了,而不是变成了喝杯咖啡的借口。

基准仓库上的速度数字是一回事;生产环境的采用才是真正的信号。根据 Biome 官方网站,该工具链已在以下公司的生产环境中运行:AWS、Google、Microsoft、Canonical、Cloudflare、Coinbase、Comcast、Discord、Node.js、Slack、Socket、Uniswap、Vercel 和 Astro。
这份名单很重要的原因有两个。首先,其中几家公司的代码库拥有数十万级别的文件,在那里 56 倍的 linting 加速不是锦上添花,而是 CI 从一分钟完成变成十五分钟完成的区别。其次,它表明 Biome 的规则覆盖已经成熟到大型团队信任它能捕获 ESLint 以前能捕获的那些 bug。
在发布方面,Biome 2026 年的路线图帖子确认项目在 2025 年底发布了 v2.0("Biotype"),增加了早期类型感知 linting,随后在 2026 年 2 月发布了 v2.4。类型感知 linting 之前是 ESLint 通过 typescript-eslint 拥有的最明显优势之一,弥合这一差距去除了团队留在旧技术栈的最后一个主要原因。
公平的比较不仅仅是速度。以下是两个技术栈在实际影响团队日常工作流程方面的对比,基于 PikVue 2026 年对 Biome、ESLint 和 Oxlint 的对比以及 Biome 自己的 linter 文档:
诚实的结论:如果你的项目依赖一长串针对特定框架的小众 ESLint 插件,在切换之前请先确认 Biome 是否有覆盖。对于大多数使用标准 JS/TS/React linting 和 Prettier 格式化的项目,Biome 现在以一小部分工具开销覆盖了核心用例。
迁移现有项目通常是一个当天就能完成的任务。安装 Biome 并初始化配置:
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init
这会生成一个 biome.json 文件。要将你现有的 ESLint 和 Prettier 设置作为起点拉入而不是从零开始:
npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write
然后用一个命令运行两项检查:
npx @biomejs/biome check --write ./src
这个单一命令对目标目录进行 linting 和格式化,应用安全的自动修复。大多数团队会在整个仓库上运行一次,审查 diff,将其作为独立的格式化提交提交,然后在下一次提交时将 biome check 接入 CI 和 pre-commit hook,替代旧的 eslint 和 prettier --check 步骤。
Biome 是 ESLint 和 Prettier 的完全替代品,还是与它们一起使用?
它被设计为完全替代品。Biome 在一个二进制文件中重新实现了 linting 和格式化,大多数团队在迁移后会完全移除 ESLint 和 Prettier,而不是并行运行。
切换到 Biome 会破坏我现有的 ESLint 配置吗?
Biome 提供了一个 migrate eslint 命令,它会读取你现有的 .eslintrc 并将支持的规则自动映射到 biome.json,尽管高度自定义的插件规则可能需要手动审查。
Biome 支持 React、Vue 和其他特定框架的 linting 吗?
Biome 原生覆盖 JSX 和 TypeScript,自 2024 年以来一直在稳步缩小特定框架规则的差距,但 ESLint 生态中某些小众框架插件可能还没有直接的 Biome 等价物。
Biome 只是关于速度,还是能捕获不同的 bug?
速度是标题,但 Biome 的规则集(500+ 条规则)与常见的 ESLint 和 typescript-eslint 配置高度重叠,其 2026 年版本增加了以前需要单独 typescript-eslint 插件的类型感知检查。
哪些公司实际上在生产环境中使用 Biome,而不是只是测试?
Biome 自己的网站列出了 AWS、Google、Microsoft、Canonical、Cloudflare、Coinbase、Comcast、Discord、Node.js、Slack、Socket、Uniswap、Vercel 和 Astro 作为生产用户,这对于评估它是否足够成熟以值得信任的团队来说是一个强烈的信号。
2026 年选择 Biome 的理由不仅仅是它很快,而是因为这种速度来自于移除了一整类大多数团队已经停止质疑的工具开销。一个二进制文件代替两个工具。一份配置代替两份。Lint 和格式化运行以毫秒而不是秒来计量,在这种规模上,这种差异在每一次提交、每一次 CI 运行和每一个开发者的保存格式化习惯中都会复合。
对于每个重度 ESLint 插件配置的设置来说,它还不是一个完美的即插即用替代品,但对于大多数 JavaScript 和 TypeScript 项目实际需要的 linting 和格式化形状而言,这个曾经感觉像锦上添花的升级正在迅速成为默认选择。如果你的 CI 管道仍在等待 Node 启动 linter,那就是 Biome 被构建来消除的瓶颈。