写过前端的都以为 lint type-aware 规则只能靠 tsc 铺垫，今天 Oxlint 用一个架构把这件事彻底变了

写过前端的都以为 lint type-aware 规则只能靠 tsc 铺垫，今天 Oxlint 用一个架构把这件事彻底变了。

什么意思？

ESLint 跑得快，但 type-aware 规则极慢——这件事几乎每个团队都默默接受了。no-floating-promises、no-misused-promises、await-thenable 这些规则需要理解「类型在程序里怎么流动」，单看一个文件根本判断不了，必须依赖类型检查器。以往的解法是在 ESLint 配置文件里加 tsc --noEmit 做类型铺垫，但这样一来，你本来并行飞奔的 ESLint 进程就变成了「等 tsc 跑完才能开始 lint」，等于自己把自己拖慢了。

这还没有算上 typescript-eslint 自己的类型感知规则开销——每次都要重新走一遍类型解析，整个流程下来一个中大型仓库跑 type-aware lint 动不动就几十秒甚至几分钟。团队要么放弃 type-aware 规则保速度，要么咬牙等 CI 慢慢跑。

Oxlint 解决这个问题的方式是把架构彻底拆开：两层二进制，各干各的事。

Rust 原生的 oxlint CLI 负责文件遍历、路径解析、执行不需要类型信息的规则——这一块极快，Rust 没有 GC 停顿，内存布局确定，遍历几千个文件几乎是瞬间的事。

类型感知的规则交给另一个二进制：tsgolint。这个名字里的「tsgo」就是关键——它是 TypeScript 编译器的 Go 语言重写版本，由 Go 社区维护，行为和 tsc 完全一致但跑得更快。Oxlint 通过它拿到完整的类型信息，再用这些信息跑 type-aware 规则。

最直接的证据：Vue 核心仓库，用 tsgolint 做 type-aware linting，耗时 2.5 秒；同一套规则在 ESLint + typescript-eslint 下跑，要 20.8 秒。差了 8 倍多。

切到 tsgolint 模式只需要两个安装步骤和一个 flag：

npm add -D oxlint oxlint-tsgolint@latest
npx oxlint --type-aware

然后你就能解锁大约 43 条 type-aware 规则：no-floating-promises、no-misused-promises、await-thenable、no-deprecated、strict-boolean-expressions……这些以前因为性能问题被禁用的规则，现在可以全量打开。

这套架构对大型 monorepo 特别友好。由于类型信息由独立的 tsgolint 进程管理，理论上可以把 type-aware linting 分布到多台机器上跑——tsgolint 读的类型信息和 tsc 是同一套源码，不需要额外的类型构建产物。

Shopify、Airbnb、Mercedes-Benz 已经在 CI 里把 Oxlint 作为第一道门禁，用来替代原来跑在 ESLint 上的 type-aware 规则。GitHub 上 graphql/graphiql 项目则给出了一个完整的迁移参考：他们移除了 15 个 eslint 相关包，换上 oxlint + oxlint-tsgolint，更新脚本里的 eslint 为 oxlint，迁移过程全程有 commit 记录可查。

还有一层工程价值：Oxlint 不需要你一次性全换掉 ESLint。可以先跑 Oxlint 抓住大多数问题，再用 eslint-plugin-oxlint 让 ESLint 对 Oxlint 已经覆盖的规则闭嘴，两个工具并存一段时间逐步切换。

目前唯一的坑：tsgolint 驱动的 type-aware linting 在 2026 年中仍处于 alpha 阶段，官方建议在 mission-critical 的 CI 流程里保留 ESLint 作为 fallback。换句话说：先用上，体验收益，等正式版出来后平滑接替。

Type-aware linting 终于从「理论上可行，但太慢没人用」，变成了「生产级别，下一版本可以直接跑在 CI 第一道门禁里」。如果你团队一直在 TypeScript 项目里忍受着 type-aware 规则跑不动，现在有了完全不同的选择。

下一步：在项目里跑一遍 npx oxlint --type-aware，看看能扫出多少以前被禁用的 type-aware 规则能重新开起来。