用 Biome 替代 ESLint + Prettier 三个月后:这套 Rust 工具链到底能不能打
说实话,当初看到 Biome 这个名字的时候我是拒绝的——ESLint 和 Prettier 用了这么多年,换套工具链的迁移成本摆在那,谁没事折腾这个。但 Biome 1.0 正式发布之后,GitHub stars 直接冲到了 3 万多,Discord 活跃度翻了倍,我实在忍不住拿手上的两个真实项目跑了一遍。
结论先说:中小型团队可以直接切,生产环境谨慎评估,monorepo 项目要做好踩坑准备。
速度是真的快,但代价也要清楚
Biome 官方数字是「比 ESLint 快 35 倍,比 Prettier 快 10 倍」。我拿一个 2000 个文件的 React 项目实测,ESLint 跑完整扫描要 42 秒,Biome 第一次跑 1.2 秒,后续增量扫描稳定在 300 毫秒以内。这个数字我没有造假,确实是真实测量。
但这里有个前提:Biome 目前覆盖的规则数量大约是 ESLint 的 60%。如果你项目里重度依赖一些冷门 ESLint 插件,切换过去之后会发现规则不够用。官方 roadmap 说会逐步补全,但现在是 2026 年 Q3,这个 gap 依然存在。
扁平配置这件事,Biome 比 ESLint 9 做得更彻底
ESLint 9 推了 flat config,但说实话迁移文档写得一塌糊涂,社区怨声载道。Biome 的配置哲学完全不同——一个 biome.json 文件,规则、格式、导入排序全在一起,没有 extends 没有 plugins 数组,清清爽爽。
{
"$schema": "https://biomejs.dev/schemas/1.9.0/schema.json",
"organizeImports": {
"enabled": true
},
"linter": {
"enabled": true,
"rules": {
"recommended": true,
"a11y": {
"useAltText": "warn"
}
}
},
"formatter": {
"indentStyle": "space",
"indentWidth": 2,
"lineWidth": 100
}
}
对比 ESLint 9 的 flat config,Biome 这套配置年轻前端看了直点头,老前端看了心里踏实。
真正踩到的三个坑
第一个坑:Git Hooks 集成。 Biome 自带 biome check –write 可以直接改文件,配合 Husky 的 pre-commit hook 很顺手。但如果你项目里之前用的是 eslint –fix,切换过来之后要改 Husky 脚本内容,否则两个工具会打架。
第二个坑:TypeScript 类型检查。 Biome 的 linter 不做类型检查,它假设你用 tsc 单独跑类型检查。这意味着 noImplicitAny 这类规则在 Biome 里是不存在的,迁移过来之后别忘了继续跑 tsc –noEmit。我第一个月就因为漏了类型检查踩了一个运行时 bug。
第三个坑:Vue 和 Svelte 支持。 Biome 对 React 和纯 TS/JS 支持最好,但 Vue 单文件组件的支持还在 beta 阶段,Svelte 基本可用但偶发问题。如果你项目里这两种技术栈占比高,先别急着切。
迁移成本有多高?
如果是全新项目,直接用 Biome,不用犹豫。如果是从 ESLint + Prettier 迁移,我建议分两步走:
第一步: 把 Prettier 替换成 Biome,这个风险最低,收益立竿见影。配置简单,规则覆盖度高,运行速度提升明显。
第二步: 等 Biome 的 ESLint 兼容层(eslint-plugin-biome)成熟之后,再把 ESLint 也替换掉。目前这个兼容层还在活跃开发,生产使用要谨慎。
总结:什么时候该切
适合切的情况:
- 新项目起步,直接用 Biome 当默认工具链
- 中小型前端团队,对格式化一致性要求高,讨厌维护复杂 ESLint 配置
- CI/CD 流水线构建时间敏感,ESLint 拖慢了流水线速度
不适合切的情况:
- 大型 monorepo,已有成熟的 ESLint 配置体系
- 重度依赖 ESLint 插件生态(特别是一些非主流规则的插件)
- 项目里有 Vue/Svelte 混用,短期内没有重构计划
工具链这东西没有银弹,但 Biome 确实让「一个工具解决 lint + format」这件事变得真正可用了。如果你被 ESLint 配置折腾过,Biome 值得你花半天时间试试水。
评论区
登录后可评论。