Biome 实战指南：用一个 Rust 工具替代 ESLint + Prettier 全家桶

一个中型前端项目启动 ESLint + Prettier 的完整检查，平均需要 8-15 秒。当项目膨胀到 500+ 文件时，这个数字可能飙到 30 秒以上。Biome 的出现彻底改变了这个局面——同样规模的项目，它能在 1 秒内完成 Lint + Format 的全部工作。这不是微优化，而是 JavaScript 工具链从 JavaScript 运行时迁移到 Rust 原生运行时的范式转变。

🔧 一、为什么 JavaScript 工具链需要重写

📦 工具链碎片化的代价

现代前端项目的 package.json 中，光是代码质量相关的依赖就有一长串：

# 一个典型项目的 lint/format 依赖
npm install --save-dev eslint @eslint/js typescript-eslint
npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier
npm install --save-dev eslint-plugin-import eslint-plugin-vue
npm install --save-dev @typescript-eslint/parser @typescript-eslint/eslint-plugin

这些依赖加在一起，node_modules 体积轻松超过 200MB。更关键的是配置复杂度——你需要维护 .eslintrc.js、.prettierrc、.editorconfig 三套配置，还要处理 ESLint 和 Prettier 之间的规则冲突。

⚠️ 警告： ESLint 和 Prettier 的冲突是一个经典坑点。Prettier 格式化后的代码可能触发 ESLint 的规则报错，反过来 ESLint 的自动修复又可能破坏 Prettier 的格式。eslint-config-prettier 的存在本身就是这个问题的证明。

⚡ Rust 重写浪潮

Biome（前身是 Rome，2023 年 fork 后更名）并不是孤例。整个 JavaScript 工具链正在经历一轮 Rust 重写浪潮：

这些工具有一个共同特点：用系统级语言重写 JavaScript 生态的基础设施，获得数量级的性能提升。Biome 的独特之处在于，它不只替代一个工具，而是要用一个统一的工具替代整个代码质量工具链。

🎯 Biome 的定位

Biome 的野心不只是"更快的 ESLint"。它的目标是成为 JavaScript/TypeScript 的统一开发者工具平台（Unified Developer Platform），涵盖：

• ✅ Linting（替代 ESLint）
• ✅ Formatting（替代 Prettier）
• ✅ Import Sorting（替代 eslint-plugin-import 的排序功能）
• 🔜 Bundling（规划中）
• 🔜 Testing（规划中）
• 🔜 Minification（规划中）

🚀 二、性能对比与实测数据

📊 基准测试

我在同一个项目上做了实测对比，项目规模：320 个 TypeScript/Vue 文件，约 45,000 行代码。

# 测试环境
# CPU: Apple M2 Pro, RAM: 16GB
# Node.js: v20.11.0, Biome: 1.8.0

# ESLint + Prettier 完整检查
time npx eslint . --ext .ts,.vue && npx prettier --check .
# 结果: 11.3 秒（ESLint 8.2s + Prettier 3.1s）

# Biome 完整检查（Lint + Format）
time npx biome check .
# 结果: 0.32 秒

35 倍的性能差距不是理论值，是实测结果。 对比表如下：

💡 提示： Biome 的性能优势在 CI/CD 环境中尤为明显。一个需要 15 秒的 lint 步骤缩短到 0.5 秒，对于频繁提交的团队来说，节省的 CI 时间是实打实的成本。

🔬 为什么快这么多

Biome 快的根本原因不是"优化"，而是"架构不同"：

1. 单次遍历：ESLint 和 Prettier 各自解析 AST（抽象语法树），总共解析两次。Biome 只解析一次，Lint 和 Format 共享同一个 AST。
2. 零配置解析：Biome 内置了 JavaScript、TypeScript、JSX、CSS、JSON 的解析器，不需要安装 @typescript-eslint/parser 这类额外解析器。
3. Rust 原生：JavaScript 的 V8 引擎即使再快，也比不上 Rust 的零成本抽象和直接内存管理。

💡 三、从 ESLint + Prettier 迁移到 Biome

🛠️ 迁移步骤

迁移过程比你想象的简单。Biome 提供了官方的迁移命令：

# 第一步：安装 Biome
npm install --save-dev @biomejs/biome

# 第二步：初始化配置
npx biome init

# 第三步：从 ESLint 和 Prettier 自动迁移规则
npx biome migrate --from eslint
npx biome migrate --from prettier

# 第四步：检查并应用所有修复
npx biome check --write .

迁移完成后，你会得到一个 biome.json 配置文件：

// biome.json — 完整配置示例
{
  "$schema": "https://biomejs.dev/schemas/1.8.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "warn",
        "useExhaustiveDependencies": "warn"
      },
      "style": {
        "noNonNullAssertion": "warn"
      },
      "suspicious": {
        "noExplicitAny": "warn"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "asNeeded"
    }
  },
  "files": {
    "ignore": ["node_modules", "dist", ".output", "*.min.js"]
  }
}

📌 记住： 一个 biome.json 就替代了 .eslintrc.js + .prettierrc + .editorconfig 三个配置文件。这不只是文件数量的减少，更是心智负担的降低——你不需要再理解三个工具之间的交互和优先级。

🔄 Git Hooks 集成

在项目中集成 Git Hooks，确保提交前自动检查：

// package.json 中添加 scripts
{
  "scripts": {
    "check": "biome check .",
    "check:fix": "biome check --write .",
    "format": "biome format --write .",
    "lint": "biome lint ."
  }
}

# 使用 simple-git-hooks（轻量方案，比 husky 更简单）
npm install --save-dev simple-git-hooks lint-staged

# package.json 配置
# simple-git-hooks 自动在 npm install 时安装 hook
{
  "simple-git-hooks": {
    "pre-commit": "npx lint-staged"
  },
  "lint-staged": {
    "*.{js,ts,vue,json,css}": "biome check --write"
  }
}

这个配置的效果是：每次 git commit 时，Biome 只检查暂存区的文件，100 个文件的检查通常在 50ms 内完成。相比 ESLint + Prettier 动辄 5-10 秒的 pre-commit 等待，开发体验有质的提升。

⚠️ 迁移中的常见坑点

坑点 1：规则覆盖率差异

Biome 目前还没有实现 ESLint 的所有规则。在迁移前，用官方的规则覆盖对比工具检查：

# 检查你的 ESLint 配置中有哪些规则 Biome 不支持
npx @biomejs/biome migrate --from eslint --diagnostic-level=info

⚠️ 警告： 如果你的项目重度依赖特定 ESLint 插件（如 eslint-plugin-react-hooks、eslint-plugin-vue），先确认 Biome 是否已支持对应规则。截至 v1.8，Biome 对 React/TSX 的支持已经很完善，但 Vue SFC 的支持仍在进行中。

坑点 2：Prettier 格式差异

Biome 的格式化输出和 Prettier 不完全一致。虽然差异很小（主要是换行策略），但在大型项目中可能导致大量文件变动。建议：

1. 迁移时创建一个独立的 commit，只做格式化变更
2. 用 biome format --write . 一次性格式化所有文件
3. 在 PR 描述中说明格式化工具已切换

坑点 3：monorepo 支配

在 monorepo 中，可以在根目录和各子包分别配置 biome.json。Biome 会自动向上查找配置文件并合并：

my-monorepo/
├── biome.json          # 根配置（共享规则）
├── packages/
│   ├── app/
│   │   └── biome.json  # 覆盖特定规则
│   └── lib/
│       └── biome.json  # 覆盖特定规则

🔮 四、Biome 的局限与未来

🚫 目前不适合的场景

诚实地说，Biome 还不是万能的。以下场景建议暂缓迁移：

✅ 适合立即迁移的场景

• ✅ 新的 TypeScript/React 项目
• ✅ 纯 JavaScript/Node.js 项目
• ✅ 对 CI 速度敏感的团队
• ✅ 受够了 ESLint 配置地狱的团队
• ✅ CSS/JSON 文件也需要格式化的项目

🔮 生态发展路线

Biome 的 2026 路线图有几个值得关注的方向：

1. Vue SFC 完整支持：<template>、<script>、<style> 三个块的完整 lint
2. 多语言扩展：CSS lint 已经在实验阶段，未来可能支持 HTML、Markdown
3. 插件系统：允许社区编写自定义 lint 规则
4. LSP 集成：更深度的编辑器集成，实时 lint + format

📋 总结

Biome 代表的不只是一个更快的 linter，而是 JavaScript 工具链从"拼凑式"走向"一体化"的趋势。当一个 Rust 工具能以 35 倍速度、零配置冲突完成 ESLint + Prettier 的全部工作时，继续维护那套复杂的工具链就变得很难自圆其说了。

我的建议很直接：

• 新项目：直接用 Biome，没有理由不选它
• 存量项目：先在 CI 中并行运行 Biome 和 ESLint，验证规则覆盖度后再切换
• 大型团队：选择一个子包试点，积累经验后再推广

⚡ 关键结论： Biome 的迁移成本远低于你的想象，但性能提升和开发体验改善是实实在在的。在一个 biome.json 替代三个配置文件、0.3 秒替代 11 秒的时代，拥抱变化是值得的。

📦 相关工具推荐：

• Biome 官方文档 — 完整的迁移指南和规则参考
• Biome Playground — 在线体验 Biome 的 lint 和 format
• jsjson.com JSON 格式化工具 — 在线格式化和校验 JSON
• jsjson.com 代码格式化标准 — 配合 Biome 建立团队代码规范