JavaScript Oxidation Compiler(Oxc)一览

Oxc,即 JavaScript Oxidation Compiler(JavaScript 氧化编译器),是一套用 Rust 编写的高性能 JavaScript 与 TypeScript 工具集合。它们构建在共享的 parser 和 AST 之上,因此 linter、formatter、transformer、minifier 和 resolver 不会各自重复解析你的代码。

如果你曾在一个大型 monorepo 上启动 lint,然后去泡了杯咖啡,回来发现它还在跑,那你已经明白为什么用 Rust 重写 JavaScript 工具链会获得如此多的关注。这段等待时间,乘上每一位开发者、每一个 CI 任务,基本上就是 Oxc 存在的理由。

它是 VoidZero 工具链之下的编译器层;从 Vite 8 开始,每一次 Vite 构建中真正完成语言层面工作的,就是这套机器。

如果你的 ESLint/Babel/Prettier 流水线很慢,并且一直在关注 Rust 工具链这波浪潮(esbuild、SWC、Biome、Oxc),那么真正实用的问题不是”Oxc 快不快?“,而是”今天哪些部分已经可以用于生产,以及它与我现有的工具如何取舍?”本文回答的正是这些:Oxc 是什么、包含哪些组件、现在可以安全采用哪些部分,以及它与替代方案相比处于什么位置。

什么是 Oxc(JavaScript Oxidation Compiler)?

Oxc 是一套 Rust 原生的 JavaScript 与 TypeScript 工具集,它们共享同一个 parser 和 AST,因此行为保持一致,也不会有任何工具重复做解析工作。这个名字致敬了 Rust:铁被氧化(oxidise)之后就成了 rust(铁锈)。在这个项目里,速度被视为必须交付的产品特性,而不是一个令人愉快的副作用,其逻辑是:更快的 linter 意味着本地更紧凑的”编辑—检查”循环,以及更低的 CI 账单。

Oxc 的意义超出其自身 CLI 的原因在于,它是现代 Vite 技术栈之下的编译器。Rolldown 是一个 Rust 打包器,它把语言层面的工作(包括解析和压缩)交给 Oxc 处理。从 Vite 8 开始,这三层由协同推进的团队共同构建:Vite 作为构建工具,Rolldown 作为打包器,Oxc 作为两者之下的编译器。因此,即便开发者从未安装任何 Oxc 包,他们的每一次构建也都在运行 Oxc 的 parser 和 transformer。

在把流水线押注其上之前,还有一些归属背景值得了解。2026 年 6 月 4 日,Cloudflare 宣布收购 VoidZero —— 这家开源公司维护着 Vite 及其周边工具,Oxc 也在其中。双方均表示项目将继续保持开源与厂商中立,Vite、Vitest、Rolldown、Oxc 和 Vite+ 全部仍采用 MIT 许可证,同时 Cloudflare 向一个面向 Vite 维护者和贡献者的独立基金投入了 100 万美元。VoidZero 本身则是由 Vue.js 作者尤雨溪(Evan You)于 2023 年创立。

各个组件及其替代对象

Oxc 以独立、可组合的组件形式发布,因此你可以只采用其中一个而不必全盘引入。每个组件都针对一个缓慢的、基于 JavaScript 的现有工具:

Parser 是整个体系的锚点。其他每个组件都读取它的输出,这也正是 Oxc 能够自称为”一条工具链”而非”六个恰好用 Rust 写成的工具”的原因。

Oxc 为什么快?

Oxc 的速度来自架构设计,而非微优化。三个关键选择贡献了大部分收益。第一,它是编译型的 Rust 而不是解释型的 JavaScript,因此热点路径以原生速度运行,并避免了垃圾回收停顿。第二,所有工具都在同一个共享 AST 上操作,消除了 ESLint、Prettier 和 Babel 各自单独解析同一文件时产生的重复解析。第三,AST 节点在内存 arena 中分配,便于低成本批量释放,而分析过程则在多个 CPU 核心上并行执行。

收益是有实测数据的,但这些数字来自项目自身的基准测试,请据此看待。VoidZero 报告称 Oxlint 比 ESLint 快 50 到 100 倍,Oxfmt 的吞吐量达到 Prettier 的 30 倍以上,在无缓存的首次运行中约为 Biome 的 2 到 3 倍,而 Rolldown 的构建速度比 Rollup 快至 10-30 倍。Biome 的数字之所以是一个区间,是因为 Oxc 自己的资料并不一致:formatter 文档给出 2 倍,beta 发布公告给出 3 倍。不同机器上的不同基准测试会得出不同结果;性能优势的量级是真实的,但具体倍数在你自己的仓库上跑过之前都只是营销说法。

今天 Oxc 中哪些部分已可用于生产?

Oxc 的成熟度取决于你如何使用每个工具。Oxlint 和 parser 作为独立组件确实已达生产级;transformer 和 minifier 作为 CLI 尚处于 1.0 之前,但它们已经在 Rolldown 和 Vite 8 内部运行于生产环境;Oxfmt 处于 beta。

Oxlint 无疑是最突出的一个。它在 2025 年 6 月发布了稳定的 1.0,发布说明中将 Shopify、Airbnb 和 Mercedes-Benz 列为生产用户;目前它处于 1.x 线上,拥有 844 条内置规则。Oxlint 同样支持类型感知 linting:tsgolint 后端将 TypeScript 自身的类型系统接入 Oxlint 的 CLI 和配置格式,覆盖了 typescript-eslint 提供的 61 条类型感知规则中的 59 条。需要如实指出的注意事项是:该功能需显式启用,需要在 Oxlint 之外单独安装 oxlint-tsgolint 包,而该包的版本号跟随其所基于的 TypeScript 发布版本而非 Oxlint 的版本,因此两者的发布节奏并不同步。在完善覆盖率和性能的同时,团队也明确排除了 typescript-eslint 规则集之外的规则,这意味着目前无法编写自定义的类型感知规则。

不要把”transformer 和 minifier 尚处于 1.0 之前”理解为”尚未可用于生产”。两者已经在每一次 Vite 8 构建中运行。Vite 8 迁移指南明确说明了分工:Oxc 从 esbuild 手中接过了 JavaScript 转换和 JavaScript 压缩,而 Lightning CSS 成为 CSS 压缩的默认方案。与此同时,Oxfmt 已从 alpha 进入 beta,现已通过 Prettier 完整的 JavaScript 与 TypeScript 一致性测试套件,但 npm 上仍标注为 Beta,因此它适合作为试点,而不是立刻整体替换 Prettier。

Oxc 与 SWC、Biome 的比较

最常见的比较误区,是把 Oxc 放在速度维度上与 SWC 对比。它们处在不同的层次。SWC 是一个被框架内嵌的编译器平台:Next.js 掌控着自己的 SWC 接缝,你不该为了追一张基准测试图表就把它拆掉。Oxc 的 transformer 与 SWC 和 Babel 竞争,但 SWC 没有官方的 linter 或 formatter,因此 **Oxlint 竞争的对象是 ESLint 和 Biome,而不是 SWC。**Biome 才是更接近的对手:它是一个 Rust 工具,在单个二进制中同时完成 lint 和 format,而 Oxc 则把 Oxlint 和 Oxfmt 保持为可独立组合的组件。

据此,务实的做法是现在就采用 Oxlint,并观察其余部分的进展。把它作为 CI 中快速的第一遍检查运行,同时保留 ESLint 来覆盖它尚未支持的规则和插件:

{
  "scripts": {
    "lint:fast": "oxlint",
    "lint": "oxlint && eslint ."
  }
}

为减少重叠,官方文档建议使用 @oxlint/migrate 来转换现有的 ESLint 配置,并配合 eslint-plugin-oxlint 关闭 Oxlint 已经处理的规则。这样你既能在快速路径上拿到速度收益,又不会在完整运行中牺牲 ESLint 的覆盖面。

Oxc 已经从”一个有前景的 Rust 项目”跨越为数百万次构建所依赖的基础设施,但其各个部分的成熟度并不均衡。从 Oxlint 开始(稳定、快速,并且与现有 linter 并行使用风险很低),在一个分支上试点 Oxfmt 以检查 diff,并让 transformer 和 minifier 通过 Vite 8 间接进入你的项目,而不是单独采用它们。随着 1.0 之前的组件逐步毕业,再重新评估;整体方向已经足够清晰,可以据此做规划。

常见问题

我可以同时运行 Oxlint 和 ESLint,还是必须二选一?

两者可以同时运行,而且同时运行正是推荐的采用路径。把 Oxlint 作为 CI 中快速的第一遍检查,同时保留 ESLint 来覆盖 Oxlint 尚未支持的规则和插件。Oxc 文档建议使用 '@oxlint/migrate' 转换现有的 ESLint 配置,并使用 'eslint-plugin-oxlint' 关闭 Oxlint 已经处理的 ESLint 规则,这样在同时运行两个 linter 时可以消除重复工作。

Oxc 会取代 SWC 吗?我该不该把 SWC 从 Next.js 中移除以改用 Oxc?

不该。Oxc 的 transformer 与 SWC 和 Babel 竞争,但你不应为了追求基准测试成绩,就把 SWC 从内嵌它的框架(如 Next.js)中拆除。SWC 是框架在内部掌控的编译器平台,而且 SWC 没有官方的 linter 或 formatter,因此 Oxlint 竞争的对象是 ESLint 和 Biome,而不是 SWC。安全的采用切面是 Oxlint,而不是替换框架内置的编译器。

Oxc 和 Biome 有什么区别?

Biome 是一个同时完成 lint 和格式化的单一 Rust 二进制文件,而 Oxc 把 linter(Oxlint)和 formatter(Oxfmt)保持为可独立采用、可组合的组件。Oxc 的范围也更广:它包含 parser、transformer、minifier 和 resolver,为 Rolldown 和 Vite 8 提供支撑,而 Biome 聚焦于 lint 与格式化这一层。在无缓存的首次运行中,VoidZero 的基准测试显示 Oxfmt 大约比 Biome 快 2 到 3 倍;Oxfmt 文档与 beta 发布公告对这一对比给出的数字并不一致。

Cloudflare 收购 VoidZero 会影响 Oxc 是否继续保持开源吗?

不会。Cloudflare 于 2026 年 6 月 4 日收购了 VoidZero,双方均表示这些项目将继续保持开源和厂商中立。Vite、Vitest、Rolldown、Oxc 和 Vite+ 仍采用 MIT 许可证,同时 Cloudflare 承诺向一个新的独立 Vite 生态基金投入 100 万美元,用于支持与 VoidZero 和 Cloudflare 均无关联的维护者和贡献者。MIT 许可意味着无论归属如何变化,现有的 fork 和使用方式都不受影响。