Oxc（The Oxidation Compiler）是一个用Rust编写的高性能JavaScript和TypeScript工具集合，提供了极速的开发体验。无论你是前端开发者还是Rust爱好者，这个完整的教程将帮助你在5分钟内快速搭建JavaScript开发环境！
什么是Oxc？
Oxc是一个基于Rust构建的现代化JavaScript工具链，包含解析器（Parser）、格式化器（Formatter）、代码检查器（Linter）、转换器（Transformer）和压缩器（Minifier）等核心组件。Oxc的设计目标是提供极致性能和开发者友好的体验。
Oxc官方文档：https://www.oxcjs.com/
如果你写过超过10万行的前端项目，一定对这种场景不陌生：保存代码后，编辑器右下角的ESLint图标转个不停；CI流水线里，静态检查环节占了80%的时间；改一行代码，热更新要等3秒以上。
这些问题的根源很简单：我们用JavaScript写的工具，已经跟不上JavaScript项目的规模了。直到Oxc出现。
先搞清楚：Oxc到底是什么？
很多人说Oxc是“Rust写的ESLint”或者“更快的Prettier”，这都太小看它了。
Oxc的全称是The Oxidation Compiler（氧化编译器，因为Rust的吉祥物是螃蟹，而氧化就是生锈的过程），它不是一个单点工具，而是一整套用Rust重写的前端工具链底座。它把前端开发最核心的6件事——解析、lint、格式化、转换、模块解析、压缩——全部重新做了一遍，而且每一件都做到了当前最快。
更重要的是，它不是把这些工具简单地堆在一起，而是从架构上让它们共享同一个底层。这才是它能比现有工具快几十上百倍的根本原因。
为什么Oxc能快到离谱？
很多人会说“因为用了Rust”，但这只是一半的答案。Biome也是Rust写的，但Oxc比它还要快3倍左右。真正拉开差距的，是Oxc的架构设计。
1. 内存管理：把GC彻底踢出编译流程
JavaScript写的工具最大的性能瓶颈是什么？是垃圾回收（GC）。ESLint在遍历AST的时候，会创建几百万个对象，然后又丢弃，这会触发频繁的GC，把CPU时间都浪费在内存管理上。
Oxc用了一种叫Arena Allocation（区域分配）的技术。简单说，就是在编译开始前，一次性开辟一块大的连续内存，所有AST节点都在这块内存里分配，编译结束后，一次性把整块内存释放。
没有了频繁的malloc和free，没有了GC停顿，内存访问的局部性也大大提升，性能自然就上去了。
2. 零拷贝解析：能不复制就不复制
传统的解析器在处理字符串的时候，会把每个token都复制一份新的字符串对象。比如解析const name = "oxc"，会为const、name、oxc分别创建新的字符串。
Oxc的解析器几乎不做任何复制。它所有的token都只是指向原始源代码的一个引用（起始位置和长度）。整个解析过程，除了AST节点本身，几乎没有额外的内存分配。
这不仅节省了内存，更重要的是节省了内存带宽——这在现代CPU上是比计算更宝贵的资源。
3. 共享AST：一次解析，多次使用
这是Oxc最核心的架构优势，也是它和所有其他工具最大的区别。
想想你现在的工具链：ESLint会解析一遍代码，Prettier会再解析一遍，TypeScript编译器又会解析一遍，Babel还要再解析一遍。同样的代码，被不同的工具重复解析4、5次，这是多大的浪费？
Oxc的设计是：解析一次，生成一个AST，然后所有工具（lint、format、transform、minify）都共享这个AST。
这意味着，当你运行oxlint && oxfmt的时候，代码只会被解析一次。未来，当Oxc的工具链完全成熟后，你的整个构建流程可能只需要解析一次代码，这带来的性能提升是指数级的。
现在就能用的工具，每一个都能让你爽到
Oxc不是一个画饼的项目，它的核心工具已经非常成熟，完全可以在生产环境使用。
Oxlint：让ESLint看起来像个古董
Oxlint是Oxc生态里最成熟的工具，也是目前最快的JavaScript linter。
官方数据是比ESLint快50-100倍，这不是跑分，是真实项目里的实测数据。我自己的一个30万行的React项目，ESLint全量检查要跑1分20秒，Oxlint只需要1.2秒。
更重要的是，它的兼容性做得非常好：
- 已经实现了700+条规则，覆盖了ESLint核心和大部分常用插件（React、TypeScript、Import、Unicorn等）
- 支持ESLint的JS插件，你现有的自定义规则几乎不用改
- 提供了自动迁移工具
@oxlint/migrate，能一键把你的.eslintrc转成Oxlint配置 - 支持真正的类型感知lint，用的是微软官方的TypeScript Go端口（tsgo），而不是自己实现的类型系统
现在很多大公司已经把ESLint换成了Oxlint，包括Elastic、Sentry、PostHog这些明星项目。
Oxfmt：格式化再也不会卡了
Prettier什么都好，就是太慢了。格式化一个大文件要等好几秒，这在写代码的时候是非常打断思路的。
Oxfmt比Prettier快30倍，比Biome快3倍。在我的机器上，格式化整个项目（1000多个文件）只需要0.3秒，快到你几乎感觉不到它的存在。
它的输出和Prettier几乎完全一致，官方说已经通过了100%的Prettier JavaScript和TypeScript测试。任何格式化差异都会被当作bug处理。
而且它内置了很多Prettier需要插件才能实现的功能：
- 导入排序
- Tailwind CSS类排序
- package.json字段排序
- 嵌入式格式化（CSS-in-JS、GraphQL等）
替换Prettier几乎不需要改任何配置，只要把prettier命令换成oxfmt就行。
其他工具：正在快速补齐
除了lint和format，Oxc的其他工具也在快速成熟：
- Parser：比SWC快3倍，通过了所有Test262 Stage4测试，是目前最标准的JS/TS解析器
- Transformer：替代Babel，支持TypeScript、JSX转换，React Fast Refresh等
- Resolver：比webpack的enhanced-resolve快28倍，行为完全一致
- Minifier：还在alpha阶段，但已经比Terser快很多，未来会成为Rolldown的默认压缩器
Oxc的真正野心：统一整个前端工具链
如果Oxc只是做了更快的ESLint和Prettier，那它还不足以被称为“未来的底座”。它真正的目标，是成为整个前端生态的基础设施。
你可能已经听说过Rolldown——Vite未来的默认打包器。而Rolldown，就是完全构建在Oxc之上的。
Vite 8已经默认使用Rolldown作为打包器，这意味着：
- 模块解析用的是oxc-resolver
- 代码转换用的是oxc-transformer
- 代码压缩用的是oxc-minifier
也就是说，当你升级到Vite 8的时候，你已经在不知不觉中使用Oxc了。
这只是开始。未来，TypeScript编译器、测试运行器、代码分析工具……所有和JS/TS处理相关的工具，都可能基于Oxc构建。
现在就可以开始用了
如果你想体验Oxc带来的速度提升，现在就可以动手：
1. 替换ESLint
pnpm add -D oxlint
然后把package.json里的lint脚本改成：
{
"scripts": {
"lint": "oxlint",
"lint:fix": "oxlint --fix"
}
}
2. 替换Prettier
pnpm add -D oxfmt
脚本改成：
{
"scripts": {
"fmt": "oxfmt . --write",
"fmt:check": "oxfmt . --check"
}
}
就是这么简单。不需要改任何配置，不需要学习新的语法，你就能获得几十倍的速度提升。
最后说几句
前端工具链已经停滞太久了。过去十年，我们一直在用JavaScript写JavaScript的工具，这在项目规模小的时候没问题，但当项目达到几十万、几百万行的时候，性能瓶颈就变得无法忍受。
Oxc的出现，不是对现有工具的简单优化，而是一次范式转移。它证明了，用系统级语言重写前端工具链，能带来数量级的性能提升。
更重要的是，Oxc不是一个孤立的项目，它背后有VoidZero公司的支持，有尤雨溪团队的背书，已经成为Vite官方的技术路线。这意味着，它不会像很多开源玩具一样半途而废。
如果你还在被缓慢的工具链折磨，现在就试试Oxc吧。它不会让你失望的。
