Biome 和 ESLint 怎么选？JavaScript Lint 工具新旧对决
Biome 用 Rust 重写 Lint+Format 双合一，整合检查与格式化；ESLint 提供独立规则与插件生态。本文从性能、规则覆盖、TypeScript 支持、编辑器集成与迁移路径全面对比。
新项目、追求极速反馈和零配置选 Biome（一个工具替代 ESLint+Prettier，CI 从分钟级降到秒级）；依赖特定 ESLint 插件（框架规则、安全审计）、老项目存量规则复杂选 ESLint。2026 年的趋势明确：Biome 是默认答案，ESLint 留给有插件硬依赖的团队。
一个真实的痛点
你的 package.json 是不是这样：ESLint + Prettier + 六个插件 + 三个共享配置，.eslintrc 写了 200 行，CI 光 Lint 就跑三分钟，pre-commit 等到走神？Biome 的承诺正是终结这一切：一个工具、一个配置文件、Rust 级速度——Lint 加格式化一次完成，大型仓库秒级跑完。
ESLint 的护城河
ESLint 自 2013 年起就是行业标准，真正的壁垒不在工具本身而在生态：React/Vue/Angular 官方规则集、import 排序、jsx-a11y 可访问性、security 安全审计……几千个插件覆盖了你能想到的每个细分领域。你们公司的风格指南、历史技术债豁免，大概率都编码在 ESLint 配置里——这是迁移的真实成本所在。
关键维度对比
- 性能：Biome 采用 Rust 工具链整合检查与格式化；实际收益需用相同文件集和等价规则测量；
- 格式化：Biome 内置 Prettier 兼容的格式化器，配置项极少；ESLint 需要搭配 Prettier 并解决两者规则打架的老问题；
- TypeScript/JSX：两者都支持。Biome 开箱即用；ESLint 需要 typescript-eslint 一套配置。注意 Biome 的类型感知规则（需要完整类型信息的规则，如 no-floating-promises）覆盖仍在追赶 typescript-eslint；
- 规则覆盖：Biome 已覆盖 ESLint 核心规则的大多数，插件系统（GritQL）在演进中，但长尾插件生态差距仍然明显。
编辑器与工程集成
两者都有 VS Code 官方插件（保存时修复）、pre-commit 钩子集成。Biome 的 biome.json 配置密度远低于 .eslintrc + .prettierrc 组合；Monorepo 下 Biome 单配置根管全部子包，ESLint 需要在各包间继承配置。
迁移路径
npm install --save-dev @biomejs/biome
npx biome migrate eslint --write # 自动转换 ESLint 配置
迁移命令把 .eslintrc 翻译成 biome.json，不可对应的规则会列出清单。务实策略：先并行运行（Biome 管格式化和基础规则，ESLint 只留 Biome 没有的插件规则），逐步收敛；或者直接全面切换，把缺失的规则需求记录下来逐个评估取舍。
常见问题（FAQ）
Q：Biome 能完全替代 Prettier 吗？
能，且这是它的核心场景：格式化输出以兼容 Prettier 为目标，但需比较实际变更。唯一要确认的是你们依赖的 Prettier 小众插件（如特殊语言支持）是否有替代。
Q：React 项目用 Biome 规则够吗？
Biome 已内置 hooks 依赖检查、jsx-a11y 等 React 核心规则的对应实现，日常够用；深度依赖 eslint-plugin-react 长尾规则（如复杂的 prop-types 检查）的团队需要逐条核对差异。
Q：老项目该迁吗？
Lint 耗时已影响开发体验（CI 慢、编辑器卡）就值得迁——性能收益立竿见影。ESLint 配置承载了大量定制规则的团队，先跑迁移命令看覆盖率报告再决定。
参考文档
本文依据公开文档整理，示例需按项目依赖版本验证；不将文档中的性能描述视为本项目实测结果。
