以下是vitest github问题"Vitest runs tests 3x slower than Jest"的摘要，如果印刷将需要大约24页。因此，我将在那里发现的所有想法和建议概括为更简洁的清单，如果您注意到Vitest慢慢来，您可以尝试的事情。请注意，由于创建了这个问题，因此将许多绩效改进合并为Vitest，因此此页面上的所有建议仍然相关，目标只是将它们快速，简洁，易于尝试列表放在一个位置。

概括

您控制中的事情以提高性能：

• 升级node.js。较新的节点版本更快。
• 在大多数情况下，从jsdom转换为happy-dom的速度更快，尽管需要调整/调整一些测试。 （有人注意到每个测试的进口速度更快）
• 删除或模拟重型依赖（而不是导入它们）。
• 而不是从“ barrel file”中导入依赖关系，而是从预构建的文件中导入它，或直接从实际文件中导入。 示例：
  • 而不是import { OneIcon } from 'thousands-of-icons'; do import OneIcon from 'thousands-of-icons/icons/OneIcon.vue';。这样，您就不必等待每次测试中加载和转换2,000多个图标组件。
• 在deps.experimentalOptimizer上阅读以及如何调整您的Incluber/duber/dubrude/条目设置，以提高测试的性能以及在测试运行期间如何捆绑依赖项。
• 而不是依赖依赖关系，而是将其指向预构建/CJS版本。例子：

    environment: 'happydom',
   -deps: {
   -  inline: ['element-plus']
   -}
   +alias: [
   +  {
   +    find: /^element-plus$/,
   +    replacement: resolve(__dirname, 'node_modules', 'element-plus/dist/index.full.mjs')
   +  }
   +]

• 您可以尝试--no-threads CLI参数，具体取决于您的测试，这可能会慢得多或更快。另外，可能需要调整一些测试才能使用。
• 将css: false设置为跳过测试中的CSS导入（如果您使用的是--browser，那么也许您不想要这个，但是--browser也很慢，因为...它涉及一个真正的浏览器）
）
• 将useAtomics: true设置为synchronize threads，可能会提高某些存储库的性能，但会导致节点在较旧的节点版本中崩溃。
• 将concurrent: 5增加到更高的价值，以同时进行更多测试（maxConcurrency）。
• 同样，您可以增加minThreads: 8来设置将用于运行测试的minimum number of CPU threads（另请参见：maxThreads）
• 如果您选择使用--sequence.shuffle停止使用它（或用--sequence.shuffle=false覆盖）。以随机顺序运行测试较慢，因为vitest可以缓存和对运行最慢的测试进行整体运行最慢的测试。
• 在某些情况下，测试reporter可以是瓶颈，如果您对所使用的瓶子没有特别的依恋，则可以尝试其他瓶颈，以查看性能是否有所提高。 示例：
  • vitest --reporter=tap
• 如果您有任何样式文件在文件名中包含.module（ex：sidebar.module.sass）。关注these instructions
• 将isolation关闭（--no-isolate或--isolate=false）的打开速度快3-8倍，但可能会破坏您的现有测试，要求重新编写它们。此外，它将在观察模式下引起问题。通常不是一个好主意。
• 将slowTestThreshold调整为更大。如果它没有报告为慢，那么谁会说这不是很快呢？骑那个安慰剂。