2.2 万星的 Oxc：为什么连 Vite 的下一代打包器，都要用它的解析器

如果你的前端仓库已经大到让 ESLint 变成”提交前先泡杯茶”的环节，那 Oxc 这个名字你大概率已经听过。它不是一个新 linter，而是一整套用 Rust 重写的 JavaScript/TypeScript 工具链底座——21 个月从零做到 2.2 万星，被 Vite 的下一代打包器 Rolldown 直接拿来当解析器用。

先把它的边界说清楚：Oxc 本身不是给终端用户”一键替换 ESLint”的产品，它是 VoidZero（Evan You 创立的公司，Vite 和 Rolldown 都在这）主导的一组模块化底层组件。真正能直接用的是它上面的两个命令：linter oxlint 和 formatter oxfmt。

它到底包含什么

仓库 oxc-project/oxc 目前暴露的能力分两层：

• 能直接跑命令的：npx oxlint@latest（lint）、npx oxfmt@latest（格式化）
• 作为库被别的工具调用的：oxc-parser、oxc-transform、oxc-minify、oxc-resolver（npm 和 crates.io 双发）

也就是说，你更可能是”间接”用上 Oxc——Rolldown 和 Nuxt 用它做解析，Rolldown 还用它的 transformer 和 minifier，Nova、swc-node、knip 用它做模块解析，而 Preact、Shopify、字节、Shopee 用 oxlint 做 lint。MIT 许可，官网 oxc.rs。

性能数据不是营销话术

官方 benchmarks 页面（oxc.rs/docs/guide/benchmarks）给的是一个很硬的口径：在 VS Code 仓库里，oxlint 检查 4800+ 文件只要 0.7 秒。第三方实测里，26.4 万文件的仓库上 oxlint 用了 22.5 秒，而 ESLint（不开类型检查）大约要 35 分钟——PkgPulse 的对比记录了这个数量级。

真正让我信服的不是合成 benchmark，而是几个可查的迁移案例：

• Shopify 把 lint 步骤从 75 分钟压到 10 秒（LinkedIn 上的讨论帖）
• 一位工程师的 6000+ TypeScript 文件迁移实录：ikorason.dev 记录了从”开发者嫌慢直接跳过 pre-commit”到迁移后快约 50 倍的全过程，而且他顺手给 Oxc 提了第一个 PR
• Mercedes-Benz 报告 lint 时间下降 71%，Airbnb、Zalando 也在生产环境用（PkgPulse）

关键转折：2026 年 3 月的 JS Plugins Alpha

oxlint 之前最大的劝退点是——它不能跑你现有的 ESLint 插件。2026 年 3 月 JS Plugins Alpha 之后，你的 ESLint 插件可以不改写直接跑（包括 React Compiler 规则）。Oxc 团队自己的说法很诚实：大约 80% 的 ESLint 用户今天就能平滑切换，剩下 20% 有明确的迁移路径。

配合 npx @oxlint/migrate .eslintrc.json > .oxlintrc.json，迁移成本已经降到很低。

真实使用门槛与边界

适合谁：

• 中大型 JS/TS 仓库、CI 里 lint 步骤成为瓶颈的团队
• 新项目——没有任何历史 ESLint 插件包袱
• 已经在用 Vite 8 + Rolldown 的团队（整条链子都是 Oxc，一致性最好）

不适合 / 要谨慎的：

• 重度依赖类型感知规则的项目：@typescript-eslint/no-floating-promises 这类类型检查型规则，oxlint 的 type-aware linting 目前仍是 alpha；Noqta 的迁移指南建议用 Oxlint 打底、ESLint 补缺口，两个串行跑总时间仍比纯 ESLint 快 5–10 倍
• 有自研 ESLint 插件的团队：迁移前先确认插件是否已适配 JS Plugins 机制
• 只想要”一个工具搞定 lint+format+打包”的人：那是 Biome 的叙事，Oxc 是分层组件，你需要自己组合

一个容易被忽略的坑：oxlint 的规则名带插件前缀，是 typescript/no-explicit-any 而不是 @typescript-eslint/no-explicit-any；它默认尊重 .gitignore，报 “File ignored” 时用 --no-ignore。

更大的图景：这不是一个 linter 的胜利

Vite 8 在 2026 年 3 月 GA 时，用 Rolldown 终结了”esbuild 管开发 + Rollup 管生产”的七年双打包器架构，而 Oxc 的 parser / transformer / minifier 就是这条链子的底层。Evan You 的 VoidZero 想把解析、转换、压缩、lint、format 都收敛到同一套 Rust 组件上，好处是 dev 和 prod 用同一个解析器，从根上消灭”开发能跑、上线炸掉”的那一类 bug。

换句话说，你今天为了 faster lint 装 oxlint，真正的长期收益是：你项目的整条工具链正在向同一套 AST 靠拢。对已经在用 AI 编程 Agent 的团队，这件事尤其重要——ikorason 在文里提到，Agent 会因为 pre-commit 太慢而直接 git commit --no-verify，确定性、快、可预测的工具链，正在变成代码质量的前置条件。

下一步可以做什么

1. 先零成本试一把：npx oxlint@latest .（默认开箱即用，不需要配置）
2. 想认真评估，跑 npx @oxlint/migrate .eslintrc.json，对比规则覆盖差异
3. 在 CI 里先并行双跑：oxlint 打底 + eslint-plugin-oxlint 关掉重复规则，观察一两周真实数据再决定是否全量切换
4. 关注 oxc.rs 的 benchmark 页面和你项目对标的用例，别只看别人仓库的数字

工具选型的答案从来不是”谁的 benchmark 更快”，而是”你的规则缺口和迁移成本能不能接受”。Oxc 现在到了一个值得认真评估的节点，但先在你自己的代码库上量一遍，比任何对比文章都管用。