写了三年 ESLint，每次跑全队检查都要等半小时——今天这件事被 Oxc 用 Rust 从根上彻底原生化了

你有没有过这种感觉：本地代码改了 10 分钟，ESLint 跑了 8 分钟，CI 还没过你就去吃饭了。不是你的代码有问题，是工具本身就有问题。

ESLint 和 Babel 这套工具链，底层跑在 V8 引擎上，单线程递归遍历 AST，大项目里那叫一个慢。50 万行代码的 monorepo，lint 一次半小时，这不是段子，是真实发生的事。

今天这件事被 Oxc 从根上翻了。

一行命令，45 分钟变 20 秒

Oxc（JavaScript Oxidation Compiler）是一套用 Rust 重写的 JavaScript/TypeScript 工具链，包含 parser、linter（oxlint）、resolver、transformer、minifier 五个组件，每个都是同类中最快的。

它不是 ESLint 的替代品——它是把 ESLint 底层重写了。

核心数据：

• ESLint 跑 50 万行 monorepo：30-45 分钟
• Oxc oxlint 跑同一套代码：20-30 秒
• 加速比：50-100x

Rolldown（Vite 8 的打包器）用的就是 Oxc 的 parser 和 resolver。Vite 8 能把 46 秒的打包时间压到 6 秒，Oxc 要记一功。

为什么能快这么多？

传统 ESLint 的瓶颈不在 JavaScript 语言本身，而在 V8 引擎的单线程 AST 遍历。一个 10MB 的代码库，ESLint 要串行解析每个文件，主线程被占满，CI 机器的 16 核只用了 1 核。

Oxc 怎么破的：

1. Rust 原生 + 零复制 Arena 分配器

Oxc 的 parser 是手写的递归下降解析器，AST 节点全部通过 arena allocator 分配，内存分配零成本。不像 V8 引擎要操心 GC 停顿，Rust 的所有权模型天然保证线程安全。

2. 多核并行（Rayon）

ESLint 单线程跑，Oxc 用 Rayon 库把文件级并行做进去了。16 核的 CI 机器，Oxc 能把 16 个文件同时解析，平均每个文件 2ms，50 万行代码 20 秒跑完不是魔法，是并行。

3. 共享 AST 架构

Oxc 的 parser、linter、transformer、minifier 共用同一套 AST。这意味着：parser 解析一次，五个工具都能用，不用重复解析。ESLint + Babel 双开的话，AST 要解析两遍；Oxc 一遍搞定全部。

Rolldown 就是靠这套共享 AST，把打包时的解析时间从 Vite 7 的 46 秒压到 6 秒。

三条迁移路，总有一条适合你

Oxc 提供了渐进迁移路径，不用一步到位。

路径一：oxlint 单独跑，主 ESLint 保兜底

适合场景：项目依赖 eslint-plugin-react、eslint-plugin-vue 等社区插件

# 先装 oxlint
npm install -D oxlint

# package.json 里加两条 scripts
{
  "scripts": {
    "lint:fast": "oxlint src",
    "lint:full": "eslint src"
  }
}

CI 里先用 oxlint 跑主流规则（覆盖率 90% 的规则），再用 ESLint 跑自定义插件规则。ESLint 的任务量从 100% 降到 10%，时间从 30 分钟变成 3 分钟。

路径二：自动迁移插件（eslint-plugin-oxlint）

Oxc 官方出了一个 eslint-plugin-oxlint 插件，把 ESLint 的规则配置自动翻译成 oxlint 的 flat config：

npx @oxlint/migrate

这个命令会扫描你现有的 eslint.config.js，自动生成对应的 oxlint 配置，迁移成本几乎为零。

路径三：直接切 Rolldown，连打包带 lint 一起快

如果你的项目还没升级 Vite 8，可以先试试 Rolldown 作为开发服务器。Rolldown 用了 Oxc 的 parser，本地 dev 模式速度提升明显，配合 oxlint 效果最好。

三个坑，踩过的才懂

坑一：自定义 ESLint 插件不认

oxlint 实现的是最流行的 400+ 条规则，但 eslint-plugin-xxx 这种纯 JS 的自定义插件，oxlint 不支持。如果你重度依赖社区插件，oxlint 只能当加速层，ESLint 不能完全撤掉。

解法：先用 oxlint 跑完，再跑 ESLint 只处理 plugin 规则。双开虽然麻烦，但 ESLint 的任务量已经大幅减少了。

坑二：同时跑 ESLint 会重复报警

如果你不关闭 ESLint 的对应规则，两个工具会报同一类问题，CI 会炸。需要在 ESLint config 里把 oxlint 已覆盖的规则禁用。

坑三：Rolldown 开发模式内存高

Rolldown 的开发模式内存使用是 Rollup 的 7 倍左右，16GB 以下的机器可能会有压力。如果 monorepo 规模不大，Vite 7 够用的话不用急着升。

下一步，从哪里开始

三步走：

1. 跑一次 benchmark：在项目根目录跑 time npx oxlint src，看看当前 lint 时间是多少
2. 加到 CI 里：先在 CI 里加一条 npx oxlint src，不改变现有 ESLint 配置，只是多一道快检查
3. 查规则覆盖率：跑 oxlint --print-config src 确认你的项目用到的规则 oxlint 都覆盖了

工具链这件事，早换早享受。45 分钟的 CI lint 时间，不是代码的锅，是工具的锅。Oxc 把这件事修了。