如何排查ESLint实际执行耗时远超规则统计时长的问题？

我正在对ESLint的使用做性能分析，目前用到了ESLint自带的TIMING=1环境变量，还结合DEBUG=eslint:cli-engine查看单文件耗时统计，但结果无法解释实际问题：执行单文件lint命令时，规则统计的最长耗时仅400ms（占总统计时长42%），但命令实际耗时却达到了50秒。

执行的命令及完整输出如下：

TIMING=1 DEBUG=eslint:cli-engine npx --node-options='--max-old-space-size=16240' eslint --fix --quiet --cache ./src/_test/some-test.int.test.ts

输出内容：

eslint:cli-engine Lint ./src/_test/some-test.int.test.ts +0ms
  eslint:cli-engine Linting complete in: 50192ms +49s
Rule                                    | Time (ms) | Relative
:---------------------------------------|----------:|--------:
import/named                            |   394.573 |    42.4%
@typescript-eslint/no-misused-promises  |   278.482 |    29.9%
import/order                            |   174.813 |    18.8%
import/extensions                       |    11.753 |     1.3%
react/jsx-no-constructed-context-values |     7.815 |     0.8%
import/no-unresolved                    |     6.491 |     0.7%
@typescript-eslint/naming-convention    |     5.245 |     0.6%
react/no-unstable-nested-components     |     3.266 |     0.4%
import/no-relative-packages             |     2.383 |     0.3%
css-modules/no-unused-class             |     2.338 |     0.3%

请问还有哪些性能分析工具可定位这50秒的耗时来源？可能的卡顿点在哪里？

一、可用于定位的性能分析工具 #

• Node.js内置--inspect/--inspect-brk调试工具：启动ESLint时添加--inspect-brk参数，打开Chrome DevTools的Node调试面板，在Performance标签录制完整执行流程，能看到规则执行外的模块加载、文件读取、缓存处理、TypeScript类型检查等所有阶段的耗时。命令示例：

  npx --node-options='--max-old-space-size=16240 --inspect-brk' eslint --fix --quiet --cache ./src/_test/some-test.int.test.ts
  

• ESLint全量DEBUG日志：除DEBUG=eslint:cli-engine外，启用DEBUG=eslint:*可查看ESLint初始化、配置加载、插件加载、文件预处理等阶段的详细耗时信息。
• clinic.js性能分析工具：用clinic bubbleprof生成火焰图，直观展示执行过程中各个函数的耗时占比，覆盖ESLint内部非规则执行阶段。命令示例：

  clinic bubbleprof -- npx --node-options='--max-old-space-size=16240' eslint --fix --quiet --cache ./src/_test/some-test.int.test.ts
  

• 缓存禁用对比测试：临时去掉--cache参数并保留TIMING=1，对比缓存开启/关闭时的耗时，排查缓存读写或校验是否存在异常。

二、可能的卡顿点 #

• TypeScript类型服务初始化：使用@typescript-eslint插件时，部分规则依赖TypeScript类型服务，该服务需要加载tsconfig.json、解析所有依赖类型文件，这个过程耗时极长但不会被TIMING=1统计。
• ESLint配置与插件加载：项目依赖大量ESLint插件、自定义规则或共享配置时，初始化阶段加载模块可能卡顿，尤其是模块需重新下载解析时。
• 文件预处理阶段：比如eslint-plugin-import的规则需要解析模块依赖、遍历项目文件树验证导入路径，这部分耗时不计入单个规则的TIMING统计。
• 缓存机制异常：--cache可能存在缓存文件损坏、校验逻辑耗时过长的情况，比如每次执行都需重新生成或校验大量缓存文件。
• Node.js内存与GC问题：即便设置了--max-old-space-size=16240，频繁触发GC也会增加总耗时，可通过Chrome DevTools的Memory标签排查。

内容的提问来源于stack exchange，提问作者Aaron Wilson