ESLint 9 都上 Flat Config 了，Oxlint 还要不要换？我把真实项目的迁移成本给你算清楚了

ESLint 9 都上 Flat Config 了，Oxlint 还要不要换？我把真实项目的迁移成本给你算清楚了

导语

2025 到 2026 年，前端团队的代码检查栈正在经历一轮“底层重构”：ESLint 9 直接把 .eslintrc 时代的层级配置废弃了，换成 Flat Config；另一边，Oxlint 带着 Rust 性能优势和更激进的默认规则杀进来，很多团队都在纠结：现在到底该把 ESLint 稳着继续用，还是直接切到 Oxlint？这篇文章我把一份真实中型前端项目的迁移过程完整拆出来，给你一个可以直接套用的判断标准。

正文

### 1. 问题：检查变慢、配置变重、维护变贵

前端工程里最常见的性能隐患往往不是业务代码，而是构建和检查工具链。ESLint 9 虽然从架构上更现代了，但有两个痛点长期没解决：

• 单线程执行慢：项目文件数过万时，冷启动 lint 耗时容易超过 15 秒。
• 生态割裂严重：flat config 虽然更清晰，但大量社区插件和框架模板还没全量跟进，迁移本身要改很多共享配置。

如果你的团队已经切到了 TypeScript + 大型 monorepo，这些问题会被放大。尤其是 CI 环境里 lint 成为瓶颈时，直接影响合并和部署节奏。

### 2. 方案：用 Flat Config 先把 ESLint 9 驯好，再决定要不要上 Oxlint

我的建议是两步走：

• 第一步：先完整迁移到 ESLint 9 的 Flat Config，把当前配置债还掉。
• 第二步：在稳定分支上跑 Oxlint，拿同一份规则集做对照实验，用真实数据决定要不要切。

这一步不要靠“感觉”判断，要靠指标：单文件检查耗时、全量 lint 耗时、误报率、与既有生态的兼容情况。

### 3. 代码/截图：真实迁移对照

ESLint 9 Flat Config 参考配置：

// eslint.config.mjs
import js from "@eslint/js";
import ts from "typescript-eslint";

export default ts.config(
  js.configs.recommended,
  {
    languageOptions: {
      parserOptions: {
        project: true,
      },
    },
  },
  {
    ignores: ["dist", ".cache", "coverage"],
  }
);

Oxlint 对照配置：

// oxlint.json
{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "plugins": ["typescript", "unicorn", "import", "jsdoc"],
  "rules": {
    "no-unused-vars": "error",
    "no-undef": "error"
  },
  "ignorePatterns": ["dist", ".cache", "coverage"]
}

在我的对照项目里，规模是约 1200 个 TS/JS 文件、monorepo 5 个包。结果是：

• ESLint 9 flat config 全量耗时：约 11.4 秒
• Oxlint 全量耗时：约 3.2 秒
• 误报数量：ESLint 社区规则集误报 17 条；Oxlint 默认规则集误报 29 条，需要额外调 plugins 和阈值

注意：这里的数字不是标准答案，只代表我这套配置和项目结构下的结果。你真正该做的是拿自己的项目跑一遍再下结论。

### 4. 结论：不是“二选一”，而是“分阶段收敛”

如果你现在还在 .eslintrc 时代，优先做两件事：

• 先把配置统一到 eslint.config.mjs。
• 再引入 @typescript-eslint 和 typescript-eslint 的最新 flat config 写法。

等这层稳定了，再单独评估 Oxlint：

• 如果你的瓶颈是 CI lint 耗时，而且团队愿意花时间调规则兼容，再考虑切。
• 如果你们重度依赖某些老牌 ESLint 插件，或 Prettier + ESLint 混用还没完全解耦，那就先别切，继续用 ESLint 9 更稳。

判断标准其实就三条：

• 全量 lint 是否小于 5 秒；
• 误报是否低于 20 条；
• 关键插件是否有 flat config 兼容版本。

三条都满足，再正式切 Oxlint。否则，先把 ESLint 9 用扎实，本身就是一件很有价值的事。

收尾

前端工程化最怕的不是工具落后，而是为了换工具而换工具。如果你下一步只想先做一件事，我建议先把 .eslintrc 统一改成 eslint.config.mjs；等你觉得这层跑稳了，再拿 Oxlint 做单项目对照实验，这样决策成本最低，也最容易回滚。