oxc-project/oxc

解决什么问题

JavaScript 工具链长期是 JS 写的多个独立项目拼起来的：lint、format、transpile、minify 各干各的，同一份源码被反复解析，CI 和大仓库里每次保存都要重付启动、解析和 GC 的代价。Oxc 的思路是用一套 Rust 核心（parser、transformer、minifier、resolver、linter）作为共享底座，让上层工具复用同一套前端，而不是各自重造。它真正想解决的不是「缺一个更快的 ESLint」，而是整条工具链重复劳动的问题。

有什么不同

Oxc 的差异在于它是可复用的组件集合，而不是单一工具。Rolldown（Vite 的打包器）用它的 parser 和 minifier，swc-node、knip 用它的 resolver，Oxlint 和 Oxfmt 则直接对外提供 lint 与格式化。和 ESLint 相比，代价是规则覆盖和插件生态——你换来的是速度和单二进制，换不来社区插件的长尾。和同样是 Rust 重写 Babel 流水线的 SWC 相比，Oxc 更强调做整条工具链的公共底座（并绑定 VoidZero 的统一工具链计划），而不是 Babel 的平替。parser 被设计成可以交给别的项目用，所以 Rolldown、Nuxt 的采用比任何一个 CLI 都更能说明它的价值。

适合谁

做构建工具、框架、脚手架的人应该认真看：parser、transformer、resolver、minifier 才是重点，不只是 npx oxlint。在大仓库 CI 里跑 lint 的团队是 Oxlint 的天然用户，但切换前要先核对现有 ESLint 插件是否都有对应规则。深度依赖 ESLint 插件生态、或需要与 Prettier 完全一致的格式化行为的项目应该再等等——README 里对规则数量、formatter 成熟度和兼容性写得很简略，建议拿自己的配置实测而不是看宣传。

上手成本

MIT 协议，嵌入商业工具没有障碍。实际成本主要在参与贡献需要 Rust 工具链，用 CLI 则只是一个 npm 安装（例如 npx oxlint@latest）。因为它移植或复制了其他开源项目的代码，大规模 vendoring 前值得读一下 THIRD-PARTY-LICENSE。主要风险不是技术而是结构性的：Oxc 正在成为 VoidZero 工具链的基础，API 和范围都可能变化。采用 Oxlint 的团队要做好与现有 ESLint 配置逐条对照的清单。

点评

这是一个有积累的项目而非短期爆红：2023 年初创建，约 2.3 万 star，README 列出 Rolldown、Nuxt、Preact、Shopify、字节跳动等生产使用方。HotRepo 的信号并不激进——Rust 周榜 +129、排第 11，Hacker News 只有一个 5 分帖——这正符合一个靠工具链采用而非热度传播的项目。关注度在稳步上升，有公司背书和下游依赖，弃坑风险低。结论：如果你在做工具，parser 和 resolver 可以放心采用；linter 要在核实规则覆盖之后再选择性接入。