你以为 ESLint 慢只能靠等？今天 Oxlint 把这件事从根上原生化了

写过前端的人都踩过这个坑——TypeScript 项目配了 ESLint，每次 npx eslint . 都要等半分钟起步，一个有几百个文件的仓库跑下来 CI 都快超时了。这个问题不是你的配置有问题，而是 ESLint 架构天花板就这么高，它是用 JavaScript 写的，每次 lint 都得在 V8 里一行行解析 AST，单线程跑规则。同一个仓库，今天 Oxlint v1.82.0（2026-09-07 稳定版）跑完同样的检查只需要不到一秒。差了 50 到 100 倍。

ESLint 慢不是你的问题，是架构问题

ESLint 设计于 2013 年，那时候 JavaScript 工具链没有别的选择。插件是 npm 包，规则是 JavaScript 函数，AST 是 JavaScript 对象，每个文件基本是串行处理的。对于小项目，这不是问题。但对于一个有几百个 TypeScript 文件的 monolith，每次 eslint --project . 跑 type-aware 规则都要 30 到 60 秒。慢到开发者直接跳过本地 lint commit 上车，CI 也只能分配更多时间给 lint job。

这个问题在 2023 年就开始被 Oxlint 项目尝试解决了。Oxlint 是 Vercel 主导的 Oxc 工具链中的 linter 组件，用 Rust 编写，单二进制，零依赖，500+ 内置规则。但一直有一个致命短板：没有类型感知规则。像 no-floating-promises、no-misused-promises 这种需要 TypeScript 类型信息的规则，Oxlint 一直跑不了，只能靠 ESLint + typescript-eslint。这个短板也成了很多团队说”暂时无法迁移”的最大理由。

现在这个理由不存在了。

Oxlint v1.82 + type-aware linting：速度差距从 50 倍缩小到 8 倍，但仍然快得多

2026 年 9 月 7 日发布的 Oxlint v1.82.0，配套了 type-aware linting 从 technical preview 升级到 alpha 状态。type-aware 规则由 tsgolint（Go 语言实现，基于 Microsoft typescript-go）提供支持。这次 alpha 包含 43 条类型感知规则，包括 no-floating-promises、no-misused-promises 等原来只能靠 typescript-eslint 的规则。

加了 type-aware 之后，Oxlint 还快吗？来看官方基准测试（MacBook Pro M2 Max 12 核）：

• Vue Core（3684 个文件，TypeScript type-aware 规则）：Oxlint 2.5 秒 vs typescript-eslint 20.8 秒，快了 8.2 倍
• Sentry（大型 monorepo）：Oxlint 4.4 秒 vs typescript-eslint 55 秒，快了 12.4 倍
• VSCode（巨量文件集）：Oxlint 424 毫秒 vs ESLint 24.9 秒，快了 58.7 倍

即使加了类型感知，Oxlint 仍然比 typescript-eslint 快 8 到 12 倍。这 8 倍差距意味着：本地 lint 从不可用变成随手可跑，CI lint 从独占 runner 变成几十毫秒级别。

生产环境已经验证过了

Mercedes-Benz 迁移到 Oxlint 后 lint 时间减少了 71%。Shopify、Airbnb、Zalando 都在生产环境跑 Oxlint。目前 Oxlint 每周下载量约 1520 万次（npm），GitHub 22K stars，0 安全漏洞。ESLint 仍然是绝对主流（每周 6800 万次下载），但增长已经基本停滞，而 Oxlint 还在以每 5 天一个版本的节奏高频迭代。

最大限制：没有自定义插件

Oxlint 目前不支持自定义插件。ESLint 生态里有大量社区插件——Tailwind CSS lint、JSX-a11y、无障碍规则、各种框架特定插件——这些在 Oxlint 里还不能用。如果你重度依赖这些插件，暂时只能用 ESLint 处理这一块，而把 Oxlint 当成快速预检工具。

最推荐的落地方式：Oxlint 做第一道检查（语法级规则），ESLint 只跑类型感知规则，两者并行：

# Oxlint：语法级检查，< 1s 覆盖 60% 常见问题
npx oxlint .

# ESLint：类型感知检查，在 CI 里并行跑
npx eslint --project . --no-eslintrc -c eslint.type-aware.config.js .

总 wall clock 时间从 38 秒（ESLint 全量）变成 8 秒（ESLint 只跑类型感知规则并行 Oxlint）。开发者在 commit 前就能得到即时反馈，CI 不再被 lint 占满。

现在怎么切入

如果你的项目主要是纯 JavaScript 或普通 TypeScript（不用特别多自定义插件），直接上 Oxlint：

npm install -D oxlint
npx oxlint .

Oxlint 接受 .oxlintrc.json 配置文件（与 ESLint 配置结构相近），如果你是从 ESLint 迁移，可以用 eslint-plugin-oxlint 禁用已被 Oxlint 覆盖的规则，不用重写配置。

TypeScript 项目想尝鲜 type-aware：

npm install -D oxlint oxlint-tsgolint@latest
npx oxlint --type-aware .

--type-aware 是 alpha 阶段标志，但 43 条规则覆盖了大多数原来必须跑 typescript-eslint 的场景。

结论

Oxlint 不是银弹——没有自定义插件、部分类型感知规则还不可用。但它解决了一个最核心的问题：lint 不需要等，不需要插件加载，不需要在 CI 里浪费那几十秒。对于大多数团队，把 Oxlint 当成 ESLint 的加速层来用，是 2026 年最高效的前端代码质量方案。配了三年 ESLint，今天才从根上把它原生化了。