如果要評選前端開發里最“又愛又恨”的工具，ESLint 一定榜上有名。它是事實上的代碼規范檢查標準，但也是不少人抱怨過無數次的工具 —— 太慢了。

項目一大，ESLint 跑一次要好幾分鐘，這段時間你可能去倒杯水、刷一條朋友圈都回來它還沒跑完。于是這幾年，社區里冒出來一堆更快的替代品：

?Biome：性能優先的現代工具鏈，幾乎所有操作都比 ESLint 快。

?OXlint：用 Rust 寫的類型感知 linter，速度飛快。

?Rslint：字節跳動團隊最近推出的 Go 語言實現，號稱比 ESLint 快 20~40 倍。

這些工具的崛起，說白了就是因為大家都被 ESLint 的速度折磨過。

被催了十年：并行 Lint 終于來了

其實，“能不能讓 ESLint 跑快點”早就是社區里呼聲最高的功能請求之一。Github 上在十年前就有人提議加 并行 linting —— 讓多個文件同時被檢查，而不是一份一份慢慢來。

但直到 2025 年 8 月，ESLint 團隊才終于在 v9.34.0 版本里，把這個功能真的做出來了。官方給它起了個名字：多線程Linting。

簡單來說，現在你可以在命令行里加上 --concurrency 參數，指定用多少個線程同時檢查文件。你的電腦 CPU 核心越多，提升越明顯。

官方給出的測試數據是：

?平均提速 1.3 倍左右

?最高能到 3 倍

換句話說，如果你以前要等 90 秒才能跑完一次 lint，現在可能 30 秒就結束了。對于日常開發來說，等待的焦慮感直接減少了一大半；在 CI/CD 環境里，這種提速就更明顯，能節省團隊不少時間。

為什么拖了這么久？

很多人可能會問：這功能明明很常見，為什么拖了十年？

原因其實挺現實的：

?Node.js 限制：早期沒有穩定的多線程機制，跨線程通信和緩存一致性都很麻煩。

?復雜度高：ESLint 要處理各種插件、規則和緩存，如果沒設計好，多線程反而可能更慢，甚至出 bug。

?優先級取舍：團隊資源有限，很多時候他們更關注規則系統、生態兼容性，而性能只能排在后面。

直到近幾年，Node.js 的 Worker 線程成熟了，社區壓力又大，ESLint 團隊才終于動手把這事辦了。

怎么用？

如果你升級到最新版本，只需要在命令行加上：

eslint . --cnotallow=4

就能開啟 4 個線程同時跑 lint。

一般來說，建議設置成 CPU 核心數 - 1，既能提速，也不會讓電腦卡死。

寫在最后

并行 linting 的到來，對 ESLint 來說是個里程碑。

?開發者不用再忍受“一次 lint = 一次放空”的尷尬。

?ESLint 在性能上終于追了一步，與競爭對手減少差距（雖然在性能上依舊被碾壓）。

?這功能呼聲整整十年，終于算是“欠債還上了”。

一句話總結：ESLint 終于不慢到離譜了。