前端 linter 的 2026 年：50 倍速度差是真的，但迁移的成本不在速度

ESLint 在前端工具链里的位置曾经是不可动摇的。2026 年的局面已经明显不同：Biome 和 Oxlint 用 Rust 重写了 lint 和格式化，速度差距大到改变工作流——一个被广泛引用的万文件 benchmark 里，ESLint 用了 45.2 秒，Biome 用了 0.8 秒，差距约 56 倍。更贴近日常开发的数字是：4800 个文件，ESLint 加 Prettier 约 28 秒，Biome 约 1.3 秒，Oxlint 约 0.7 秒。

速度差的工程意义不在于“省了 27 秒”，而在于lint 可以从“提交前跑一次”变成“编辑时持续跑”。当一次全量 lint 的耗时从几十秒降到一秒以内，IDE 集成、pre-commit、CI 都可以用同一套快速反馈，而不需要在“太慢所以跳过”和“等它跑完”之间做取舍。

但迁移的成本不在速度，在规则覆盖和生态兼容。Biome 的策略是实现自己的类型推断，而不是依赖 TypeScript 编译器，官方承认覆盖率仍在提升。这意味着一些依赖 TypeScript 类型信息的 ESLint 规则——尤其是 @typescript-eslint 里那些需要完整类型检查的规则——在 Biome 里可能没有等价实现，或者行为有差异。Oxlint 的规则数量也还在增长，一些插件和自定义规则的支持不完整。

一个务实的迁移判断是：先区分“格式”和“lint”。格式化（缩进、引号、换行）用 Biome 或 Prettier 替换，收益最直接，风险最低，因为格式化规则相对标准化，差异容易审查。lint 的迁移要看规则覆盖：把现有 ESLint 配置里的规则按“Biome/Oxlint 有等价实现”“有近似实现但行为不同”“没有实现”分类，后两类需要保留 ESLint 或者接受规则缺失。

一个常见的错误是“一次性全换”，结果发现某些关键规则静默失效，CI 还是绿的，问题漏到了代码评审甚至生产。更稳的路径是并行运行：Biome/Oxlint 作为快速反馈层，ESLint 保留作为完整规则层，逐步把 ESLint 的规则迁走或确认可以放弃，直到快速层能覆盖绝大多数场景。速度收益从第一天就能拿到，迁移风险被控制在规则层面。

还有一个容易被忽略的维度是编辑器集成和 CI 的一致性。Biome 和 Oxlint 的 VS Code 扩展已经可用，但如果团队同时使用多种编辑器、或者 CI 环境和本地环境的 Node 版本不同，同一个配置文件的行为可能有差异。迁移前在 CI 里用同一份配置跑一遍，对比本地结果，比直接切换更可靠。

Linter 的速度提升是真实的，它改变的是“什么时候可以 lint”的工作流。但 lint 的价值在于“抓住问题”，不在于“跑得快”。迁移的顺序应该是先拿速度收益，再逐条处理规则差异，而不是反过来——先追求 100% 规则等价，结果迁移永远完不成。