告别 ESLint + Prettier：Biome 统一工具链 + AI 代码审查实战

引言：前端工具链的”配置地狱”#

每个前端开发者都经历过这样的噩梦：新建一个项目，光是配置代码规范就要折腾半天。ESLint 配置一份、Prettier 配置一份，两者还经常打架——ESLint 说这行要加分号，Prettier 说不用。于是你又得装 eslint-config-prettier 来解决冲突，再加上 eslint-plugin-import、@typescript-eslint/parser……

一个中型 Vue 项目的 devDependencies 里，光代码规范相关的包就能有 15 个以上。

2026 年，这个局面终于有了根本性的改变。Biome（原 Rome）在 v2.0 发布后，真正实现了「一个工具干完 Lint + Format + Import 排序」的承诺，而且速度快到离谱。再配合 AI 代码审查工具，前端代码质量体系迎来了一次质的飞跃。

本文会深入聊聊：

Biome 到底好在哪，和 ESLint + Prettier 的真实对比
如何在 Vue 3 项目中完整接入 Biome
AI 代码审查工具的实战选型和接入
一套完整的 CI/CD 代码质量流水线方案

一、为什么说 ESLint + Prettier 模式该退场了#

1.1 历史包袱太重#

ESLint 诞生于 2013 年，Prettier 诞生于 2017 年。两个工具的设计哲学完全不同：

维度	ESLint	Prettier
核心目标	代码质量检查	代码格式统一
配置哲学	高度可配置	尽量少配置
解析器	基于 AST	基于 AST（但重新打印）
插件生态	海量插件	几乎不需要插件

问题在于，ESLint 后来也加了格式化规则（比如 indent、semi），和 Prettier 的职责产生了重叠。社区的解决方案是 eslint-config-prettier——关掉 ESLint 所有格式化规则，让 Prettier 接管。

但这本质上是用一个 hack 去弥补架构设计的缺陷。

1.2 性能问题不可忽视#

在一个 1000 个文件的中型项目中，我实际测过（M2 MacBook Pro）：

1
ESLint（含 TypeScript 解析）: 12.3s
2
Prettier:                     4.7s
3
两者串行:                     17.0s
4

5
Biome（lint + format）:        0.8s

快了 21 倍。 这不是理论数据，是实际项目的 time 命令结果。

Biome 用 Rust 写的，这是根本原因。但更重要的是它的架构：一次解析，多次检查。ESLint 和 Prettier 各自解析一次 AST，而 Biome 只解析一次就同时完成 lint 和 format。

1.3 配置复杂度的差距#

一个典型的 ESLint + Prettier 项目需要这些配置文件和依赖：

1
// package.json 中的 devDependencies（精简版）
2
{
3
  "eslint": "^9.x",
4
  "@eslint/js": "^9.x",
5
  "eslint-plugin-vue": "^10.x",
6
  "eslint-config-prettier": "^10.x",
7
  "@typescript-eslint/parser": "^8.x",
8
  "@typescript-eslint/eslint-plugin": "^8.x",
9
  "eslint-plugin-import": "^2.x",
10
  "prettier": "^3.x"
11
}

加上 eslint.config.js（Flat Config）和 .prettierrc，总配置量轻松超过 100 行。

Biome 呢？

1
{
2
  "@biomejs/biome": "^2.x"
3
}

一个依赖。配置文件 biome.json 通常 20-30 行就够了。

二、Biome 深入解析#

2.1 架构设计#

Biome 的核心是一个用 Rust 编写的 CST（Concrete Syntax Tree）解析器。和传统 AST 不同，CST 保留了所有语法信息，包括空格、注释、括号位置等。这意味着：

Lint 检查可以直接在 CST 上进行，不需要额外的格式信息
Format 格式化可以基于同一棵 CST 重新输出代码，不需要二次解析
Import 排序也是 CST 上的节点操作

1
源代码 → CST 解析（一次） → Lint 检查
2
                          → Format 格式化
3
                          → Import 排序
4
                          → 输出结果

这种「单次解析、多通道处理」的架构，是 Biome 性能碾压的根本原因。

2.2 在 Vue 3 项目中接入 Biome#

从 Biome 1.9+ 开始，.vue 文件已经得到了良好支持。以下是完整的接入流程：

1
# 安装
2
pnpm add -D @biomejs/biome
3

4
# 初始化配置
5
pnpm biome init

生成的 biome.json 需要做一些调整：

1
{
2
  "$schema": "https://biomejs.dev/schemas/2.0/schema.json",
3
  "vcs": {
4
    "enabled": true,
5
    "clientKind": "git",
6
    "useIgnoreFile": true
7
  },
8
  "organizeImports": {
9
    "enabled": true
10
  },
11
  "linter": {
12
    "enabled": true,
13
    "rules": {
14
      "recommended": true,
15
      "complexity": {
16
        "noExcessiveCognitiveComplexity": {
17
          "level": "warn",
18
          "options": { "maxAllowedComplexity": 15 }
19
        }
20
      },
21
      "suspicious": {
22
        "noConsoleLog": "warn",
23
        "noDebugger": "error"
24
      },
25
      "style": {
26
        "useConst": "error",
27
        "noNonNullAssertion": "warn"
28
      },
29
      "correctness": {
30
        "noUnusedVariables": "error",
31
        "noUnusedImports": "error"
32
      }
33
    }
34
  },
35
  "formatter": {
36
    "enabled": true,
37
    "indentStyle": "space",
38
    "indentWidth": 2,
39
    "lineWidth": 100
40
  },
41
  "javascript": {
42
    "formatter": {
43
      "quoteStyle": "single",
44
      "semicolons": "asNeeded",
45
      "trailingCommas": "es5"
46
    }
47
  },
48
  "files": {
49
    "ignore": ["dist", "node_modules", ".nuxt", ".output", "*.min.js"]
50
  }
51
}

添加 npm scripts：

1
{
2
  "scripts": {
3
    "lint": "biome check .",
4
    "lint:fix": "biome check --write .",
5
    "format": "biome format --write ."
6
  }
7
}

2.3 从 ESLint 迁移#

Biome 提供了一个非常实用的迁移命令：

1
pnpm biome migrate eslint --write

这个命令会读取你现有的 ESLint 配置，把能对应的规则自动迁移到 biome.json。不能一一对应的规则会以注释形式列出，方便你手动处理。

实际迁移中需要注意几个点：

1. Vue 特定规则的对应关系

1
// ESLint (eslint-plugin-vue)          →  Biome 对应规则
2
'vue/no-unused-vars'                   →  correctness/noUnusedVariables
3
'vue/no-mutating-props'                →  （Biome 暂无直接对应，需 Vue 编译器检查）
4
'vue/multi-word-component-names'       →  （Biome 暂无，可忽略或自定义）
5
'vue/require-default-prop'             →  （Biome 暂无，建议 TypeScript 类型约束替代）

2. TypeScript 规则的迁移

大部分 @typescript-eslint 规则在 Biome 中有对应：

1
// @typescript-eslint                  →  Biome
2
'@typescript-eslint/no-explicit-any'   →  suspicious/noExplicitAny
3
'@typescript-eslint/no-unused-vars'    →  correctness/noUnusedVariables
4
'@typescript-eslint/consistent-type-imports' → style/useImportType

3. 渐进式迁移策略

不建议一次性切换。推荐的做法是：

1
// 第一阶段：只启用 format，关闭 lint
2
{
3
  "linter": { "enabled": false },
4
  "formatter": { "enabled": true }
5
}
6

7
// 第二阶段：启用 lint 的 recommended 规则
8
{
9
  "linter": { "enabled": true, "rules": { "recommended": true } }
10
}
11

12
// 第三阶段：添加严格规则，移除 ESLint

2.4 IDE 集成#

VSCode 用户安装 biomejs.biome 扩展即可。配置 settings.json：

1
{
2
  "editor.defaultFormatter": "biomejs.biome",
3
  "editor.formatOnSave": true,
4
  "editor.codeActionsOnSave": {
5
    "quickfix.biome": "explicit",
6
    "source.organizeImports.biome": "explicit"
7
  },
8
  // 禁用旧的 ESLint 和 Prettier
9
  "eslint.enable": false,
10
  "prettier.enable": false
11
}

保存时自动 lint + format + import 排序，体验非常丝滑。

三、AI 代码审查：从规则到智能#

Biome 解决了「确定性规则」的检查——变量未使用、格式不统一、import 未排序。但有一类问题是传统 lint 工具搞不定的：

这段逻辑有没有边界 case 没考虑？
这个函数命名是否准确表达了意图？
这段代码有没有更优雅的实现方式？
是否引入了潜在的性能问题？

这正是 AI 代码审查工具的价值所在。

3.1 主流 AI 代码审查工具对比#

工具	集成方式	支持语言	核心特点	价格
CodeRabbit	GitHub/GitLab PR	全栈	深度 PR Review，上下文理解强	免费版够用
Sourcery	GitHub PR + IDE	Python/JS/TS	重构建议精准	开源免费
Amazon CodeGuru	AWS 集成	Java/Python/JS	安全漏洞检测	按行收费
Cursor 内置	IDE	全栈	实时 inline 建议	$20/月
Claude Code Review	CLI/CI	全栈	深度理解业务逻辑	API 按量

对于前端项目，我推荐 CodeRabbit + Biome 的组合：Biome 管确定性规则，CodeRabbit 管智能审查。

3.2 CodeRabbit 实战接入#

在项目根目录创建 .coderabbit.yaml：

1
language: "zh-CN"
2
reviews:
3
  profile: "assertive"  # 严格模式
4
  request_changes_workflow: true
5
  high_level_summary: true
6
  poem: false  # 关掉诗歌模式（认真的）
7
  path_instructions:
8
    - path: "src/composables/**"
9
      instructions: |
10
        这是 Vue 3 Composable 函数目录。审查时请特别注意：
11
        1. 是否正确处理了组件卸载时的清理逻辑
12
        2. 响应式数据是否有内存泄漏风险
13
        3. 是否遵循 useXxx 命名约定
14
    - path: "src/stores/**"
15
      instructions: |
16
        这是 Pinia Store 目录。请检查：
17
        1. State 是否使用了正确的响应式类型
18
        2. Actions 中是否有未处理的异步错误
19
        3. 是否有跨 Store 的循环依赖
20
  auto_review:
21
    enabled: true
22
    drafts: false
23
chat:
24
  auto_reply: true

这个配置的精髓在 path_instructions：你可以针对不同目录给 AI 不同的审查指令。这比通用的 AI 审查精准得多。

3.3 自建 AI 代码审查 Hook#

如果不想依赖第三方服务，可以用大模型 API 自建一个 Git pre-commit hook：

1
import { execSync } from 'child_process'
2

3
interface ReviewResult {
4
  file: string
5
  severity: 'info' | 'warning' | 'error'
6
  line: number
7
  message: string
8
  suggestion?: string
9
}
10

11
async function getChangedFiles(): Promise<string[]> {
12
  const output = execSync('git diff --cached --name-only --diff-filter=ACM')
13
    .toString()
14
    .trim()
15
  return output.split('\n').filter(f => /\.(ts|vue|js)$/.test(f))
16
}
17

18
async function reviewWithAI(
19
  filePath: string,
20
  diff: string
21
): Promise<ReviewResult[]> {
22
  const prompt = `你是一个资深前端代码审查专家。请审查以下代码变更，关注：
23
1. 潜在的 bug 和边界 case
24
2. 性能问题（不必要的重渲染、内存泄漏）
25
3. 安全风险（XSS、敏感数据暴露）
26
4. 可维护性问题
27

28
文件：${filePath}
29
变更内容：
30
${diff}
31

32
请以 JSON 数组格式返回审查结果，每项包含 severity、line、message、suggestion 字段。
33
如果没有问题，返回空数组 []。`
34

35
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
36
    method: 'POST',
37
    headers: {
38
      'Content-Type': 'application/json',
39
      Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
40
    },
41
    body: JSON.stringify({
42
      model: 'gpt-4o',
43
      messages: [{ role: 'user', content: prompt }],
44
      temperature: 0.1,
45
      response_format: { type: 'json_object' },
46
    }),
47
  })
48

49
  const data = await response.json()
50
  return JSON.parse(data.choices[0].message.content).results || []
51
}
52

53
async function main() {
54
  const files = await getChangedFiles()
55
  if (files.length === 0) {
56
    console.log('✅ 没有需要审查的文件')
57
    return
58
  }
59

60
  console.log(`🔍 AI 审查 ${files.length} 个文件...`)
61
  let hasErrors = false
62

63
  for (const file of files) {
64
    const diff = execSync(`git diff --cached -- ${file}`).toString()
65
    const results = await reviewWithAI(file, diff)
66

67
    for (const r of results) {
68
      const icon = r.severity === 'error' ? '❌' : r.severity === 'warning' ? '⚠️' : 'ℹ️'
69
      console.log(`${icon} ${file}:${r.line} - ${r.message}`)
70
      if (r.suggestion) {
71
        console.log(`   💡 建议: ${r.suggestion}`)
72
      }
73
      if (r.severity === 'error') hasErrors = true
74
    }
75
  }
76

77
  if (hasErrors) {
78
    console.log('\n❌ AI 审查发现严重问题，提交被阻止')
79
    process.exit(1)
80
  }
81
  console.log('\n✅ AI 审查通过')
82
}
83

84
main().catch(console.error)

在 .husky/pre-commit 中添加：

1
#!/bin/sh
2
# 先跑 Biome（快速，确定性检查）
3
pnpm biome check --staged --no-errors-on-unmatched || exit 1
4

5
# 再跑 AI 审查（慢一点，但更智能）
6
npx tsx scripts/ai-review.ts || exit 1

3.4 AI 审查的边界在哪#

用了一段时间后，我总结出 AI 代码审查的能与不能：

AI 擅长的：

发现逻辑漏洞（比如没处理 null/undefined 的 case）
识别安全风险（未转义的用户输入、敏感信息硬编码）
命名和可读性建议
发现 API 使用中的反模式

AI 不擅长的：

业务逻辑的正确性（它不懂你的业务）
架构层面的判断（这应该是人的决策）
性能的精确量化（它能说”可能慢”，但不能说”慢 300ms”）
团队规范的一致性（这是 Biome 的活）

所以最佳实践是：Biome 管规范，AI 管智能，人管架构。三层防线，各司其职。

四、完整的 CI/CD 代码质量流水线#

把前面的内容整合起来，以下是一个完整的 GitHub Actions 配置：

1
name: Code Quality
2

3
on:
4
  pull_request:
5
    branches: [main, develop]
6
  push:
7
    branches: [main]
8

9
jobs:
10
  biome-check:
11
    name: Biome Lint & Format
12
    runs-on: ubuntu-latest
13
    steps:
14
      - uses: actions/checkout@v4
15
      - uses: biomejs/setup-biome@v2
16
        with:
17
          version: latest
18
      - name: Run Biome
19
        run: biome ci .
20

21
  type-check:
22
    name: TypeScript Check
23
    runs-on: ubuntu-latest
24
    steps:
25
      - uses: actions/checkout@v4
26
      - uses: pnpm/action-setup@v4
27
      - uses: actions/setup-node@v4
28
        with:
29
          node-version: 22
30
          cache: 'pnpm'
31
      - run: pnpm install --frozen-lockfile
32
      - run: pnpm vue-tsc --noEmit
33

34
  unit-test:
35
    name: Unit Tests
36
    runs-on: ubuntu-latest
37
    needs: [biome-check, type-check]
38
    steps:
39
      - uses: actions/checkout@v4
40
      - uses: pnpm/action-setup@v4
41
      - uses: actions/setup-node@v4
42
        with:
43
          node-version: 22
44
          cache: 'pnpm'
45
      - run: pnpm install --frozen-lockfile
46
      - run: pnpm vitest run --coverage
47
      - uses: actions/upload-artifact@v4
48
        with:
49
          name: coverage
50
          path: coverage/

流水线执行顺序：

1
PR 提交
2
  ├── Biome 检查（~5s）     ← 最快，第一道门
3
  ├── TypeScript 类型检查    ← 并行执行
4
  └── 通过后 → 单元测试      ← 依赖前两步
5
                └── 通过后 → CodeRabbit AI 审查（自动）

Biome 放在第一位是因为它最快——如果代码连格式都不对，后面的检查没必要跑。

五、性能实测：真实项目数据#

我在一个 380 个组件的 Vue 3 项目上做了完整的对比测试：

1
项目规模：
2
- 380 个 .vue 文件
3
- 210 个 .ts 文件
4
- 45 个 .css 文件
5
- 总计约 12 万行代码
6

7
ESLint + Prettier（cold）:    28.4s
8
ESLint + Prettier（cached）:  6.2s
9
Biome（cold）:                1.1s
10
Biome（cached）:              0.3s
11

12
CI 环境（GitHub Actions）:
13
ESLint + Prettier:            42s
14
Biome:                        3s

在 CI 环境差距更大，因为没有本地缓存。

内存占用对比：

1
ESLint:   峰值 ~420MB
2
Prettier: 峰值 ~180MB
3
Biome:    峰值 ~95MB

对于 4G 内存的服务器（比如我的部署服务器），这个差距意味着 Biome 可以和构建任务并行跑，而 ESLint 就得排队。

六、Biome 的局限性和应对#

Biome 不是万能的，目前还有几个短板需要注意：

6.1 Vue 模板的深度检查不够#

Biome 对 .vue 文件 <script> 部分的检查很好，但 <template> 部分的检查能力还不如 eslint-plugin-vue。比如 v-for 没有 :key、事件修饰符的使用建议等。

应对方案：保留 eslint-plugin-vue 只跑模板相关规则，其他交给 Biome：

1
// eslint.config.js（最小化版本）
2
import pluginVue from 'eslint-plugin-vue'
3

4
export default [
5
  ...pluginVue.configs['flat/recommended'].map(config => ({
6
    ...config,
7
    rules: {
8
      // 只保留模板相关规则
9
      'vue/no-unused-vars': 'off',        // 交给 Biome
10
      'vue/html-indent': 'off',           // 交给 Biome
11
      'vue/max-attributes-per-line': 'off', // 交给 Biome
12
      // 保留这些
13
      'vue/no-mutating-props': 'error',
14
      'vue/require-v-for-key': 'error',
15
      'vue/no-template-shadow': 'warn',
16
    },
17
  })),
18
]

6.2 自定义规则#

ESLint 的插件生态是其最大优势。如果你依赖大量自定义 ESLint 插件，迁移成本会比较高。

Biome 从 2.0 开始支持通过 GritQL 编写自定义 lint 规则，但生态还在早期：

1
{
2
  "linter": {
3
    "rules": {
4
      "nursery": {
5
        "useConsistentMemberAccessibility": "warn"
6
      }
7
    }
8
  }
9
}

6.3 Monorepo 支持#

Biome 支持项目级别的配置继承，但不如 ESLint 的 cascading config 灵活：

1
// 根目录 biome.json
2
{
3
  "extends": ["./biome.shared.json"],
4
  "linter": {
5
    "rules": {
6
      "recommended": true
7
    }
8
  }
9
}

七、我的推荐方案#

根据项目阶段和团队情况，我推荐三种方案：

新项目（强烈推荐）#

1
Biome（lint + format + import）
2
+ CodeRabbit（AI PR 审查）
3
+ vue-tsc（类型检查）
4
+ Vitest（单元测试）

配置量最小，速度最快，体验最好。

存量项目（渐进迁移）#

1
第一步：Prettier → Biome formatter（低风险）
2
第二步：ESLint 简单规则 → Biome linter（中风险）
3
第三步：ESLint 只保留 Vue 模板规则（最终状态）
4
全程保留：AI 代码审查

大型 Monorepo#

1
Biome（基础 lint + format）
2
+ ESLint（Vue 模板 + 自定义业务规则）
3
+ AI 审查（PR 级别）

大型项目通常有很多自定义 ESLint 规则，完全迁移成本太高。混用是务实的选择。

总结#

前端代码质量工程化正在经历一次范式转变：

工具层面：从「多工具组合」到「单工具统一」（Biome）
检查层面：从「纯规则驱动」到「规则 + AI 智能」
流程层面：从「本地手动」到「CI 自动化全覆盖」

Biome 不是银弹，但它确实解决了前端工具链最痛的问题——太慢、太复杂、太多配置。再配合 AI 代码审查，代码质量的保障能力比两年前强了一个量级。

如果你还在忍受 ESLint + Prettier 的配置地狱，是时候试试 Biome 了。一个 pnpm add -D @biomejs/biome && pnpm biome init，5 分钟就能跑起来。

工具的终极目标不是让你花时间配置它，而是让你忘记它的存在。 Biome 正在朝这个方向走。

音乐

音乐