你以为 ESLint 的棺材板是慢慢钉的？今天 Oxlint v1.0 用三个企业数字把它一次性钉死了

写过代码的人大概都被 ESLint 的龟速 lint 折磨过——中等规模仓库跑一次要等几十秒，monorepo 更是能让人去接水回来还没跑完。这种情况在 2026 年 9 月有了实质变化：Oxlint v1.0 正式发布，带着三个真实的企业采用数字，宣告这个痛点有了原生解法。

先说数字。

Airbnb 在内部测试里用 Oxlint 跑多文件规则，126,000+ 个文件，7 秒跑完。ESLint 在同样环境下直接超时跑不完。Mercedes-Benz 切换过来之后，lint 时间下降了 97%。还有一个案例：某 monorepo 之前跑 ESLint 要 11 分钟，Oxlint 全部跑完不到 1 秒。这不是测试用例跑出来的基准，是真实生产仓库的数字。

这些数字背后是架构差异。Oxlint 来自 VoidZero（Vue 和 Vite 作者 Evan You 创立的公司），是 Oxc 工具链的 linter 组件。Oxc 的核心设计是整条工具链共享同一套 AST——Parser、Transformer、Minifier、Resolver、Linter、Formatter 六个组件各读同一棵语法树，不存在每个工具独立 parse 一遍的问题。ESLint 每次跑规则要先 parse，Babel 做转换再 parse 一遍，Prettier 格式化又 parse 一遍，monorepo 里 N 个工具对同一份代码重复 parse 的成本是隐形的。

Oxlint v1.0 的规格：520+ 条规则，零配置启动，多文件规则支持（import/no-cycle、oxc/no-barrel-file 这类需要跨文件分析的规则），支持 .oxlintrc.json 配置（兼容 ESLint v8 flat config 格式），VSCode/IntelliJ/WebStorm/Zed 插件都有。迁移路径也很直接：装好之后先跑 npx oxlint@latest，它会和现有 ESLint 共存，eslint-plugin-oxlint 插件会自动关闭已由 Oxlint 支持的规则，两个 linter 可以并行跑渐进迁移。

v1.0 之后 Oxlint 保持高频率更新，2026 年 8 月已经到 v1.80.0（2026-08-24），健康分 100/100，周下载 19.9M，2026 年已发 67 个版本。8 月的 v1.78 还合并了 AstBuilder 重构、统一了新的 builder API、修了 30+ ESLint 规则的 schema。

Oxc 工具链的其余部分进度各不相同：Resolver 已经稳定，被 Rspack 和 Rolldown 在生产环境里用着；Transformer 在 Beta 阶段，核心转换已经可用；Minifier 在 Alpha 阶段；Formatter（Oxfmt）到了 0.63 已经匹配 Prettier 的 JavaScript/TypeScript 规范套件。关键节点是 Rolldown 1.0 在 2026 年 5 月 7 日稳定发布，而 Vite 8 已经内置使用 Oxc 做 JavaScript 转换和压缩——也就是说，哪怕你从来不装 Oxlint，你每次跑 Vite 8 构建也在用它的底层能力。

还有一个值得关注的消息：2026 年 6 月 Cloudflare 收购了 VoidZero。双方承诺所有项目保持 MIT 开源许可，Vite、Vitest、Rolldown、Oxc 全部继续开源，Cloudflare 还往独立基金里投了 100 万美元保证维护者收入。这是前端的 Rust 工具链第一次有了大厂背书的商业化路径。

三个落地下一步：

第一，单文件验证。如果手上有个中等规模的 TypeScript 项目，直接跑 npx oxlint@latest，看输出质量和速度，基本秒级出结果。

第二，monorepo 双跑。在 CI 里把 Oxlint 加到 ESLint 前面——oxlint && eslint，Oxlint 失败就直接跳 ESLint，lint 时间不增反降。

第三，关注 Vite 8 默认集成。等 Vite 8 发稳定版，默认 bundler 切换到 Rolldown，Oxc 的性能收益会直接落到团队头上，不需要任何迁移动作。

Oxlint v1.0 的发布是一个信号：前端工具链的 Rust 重写已经从实验进入大规模生产验证阶段，Airbnb、Shopify、Mercedes-Benz 这些名字不是官方案例页的装饰，是真实跑在生产 CI 里的数字。