为什么Vite处理Sass比Webpack慢那么多？

设计师奕森提问于 2026-02-10 21:34:31 阅读 47

前端

我在给旧项目迁移到Vite时发现奇怪的现象，同样的Sass文件用Vite构建反而比原来的Webpack更卡顿。比如这个带变量和嵌套的CSS：


:root {
  --primary: #3498db;
  --spacing: 1rem;
}

.container {
  background: var(--primary);
  padding: var(--spacing);
  
  &__item {
    transition: opacity 0.3s;
    &:hover { opacity: 0.8 }
  }
}

在Webpack配置里用了sass-loader + MiniCssExtractPlugin，生产构建只要3秒。换成Vite后vite.config.js里直接用了sass插件，结果生产构建要5秒多，开发服务器保存时也经常卡住。已经试过：

1. 删除node_modules重装

2. 在vite.config.js里加了

optimizeDeps: { include: ['sass'] }

3. 把Sass拆分成多个小文件

还是没改善，难道Vite处理复杂Sass项目天生就比不过Webpack？是不是哪里配置错了？

我来解答赞 5 收藏

反馈

2 条解答

司徒书錦 Lv1

Vite处理Sass比Webpack慢，这个问题确实有点反直觉，但其实背后有几个关键点可以解释这个现象。我们从后端架构的角度来看，Vite的依赖解析和构建流程和Webpack有本质区别。

首先，Vite在开发模式下是基于ESBuild来处理Sass的，而ESBuild本身对Sass的支持并不是原生的，它是通过调用Dart Sass或者Node Sass来完成编译的。这种间接调用会导致额外的开销，尤其是当你的Sass文件里有大量的嵌套规则、变量计算时，性能问题会更明显。相比之下，Webpack的sass-loader是直接集成到整个打包流程中的，MiniCssExtractPlugin也能高效地抽取CSS，减少了中间环节的损耗。

其次，Vite的依赖预构建机制（optimizeDeps）虽然能加速部分场景，但对于Sass这种需要动态解析的资源并不总是有效。你提到已经在vite.config.js里加了optimizeDeps配置，但这个配置主要是针对JavaScript模块的依赖优化，对Sass的作用有限。Sass文件的解析速度更多依赖于底层实现，而不是Vite的优化策略。

解决这个问题可以从以下几个方向入手：

第一，确认你用的是Dart Sass还是Node Sass。如果你还在用Node Sass，建议切换到Dart Sass，因为Node Sass已经进入维护模式，性能也不如Dart Sass稳定。可以通过安装npm install sass来确保使用的是Dart Sass。

第二，在vite.config.js里调整Sass插件的配置，尝试开启fiber选项来加速异步解析。代码示例：

import { defineConfig } from 'vite';

import sass from 'sass';



export default defineConfig({

  css: {

    preprocessorOptions: {

      scss: {

        implementation: sass,

        fiber: require('fibers')

      }

    }

  }

});

这里引入了fibers库，它可以让Sass的同步操作变成异步，从而提升解析效率。不过要注意，fibers只支持Node.js 16以下版本，如果用的是更高版本的Node，可能需要降级或者寻找替代方案。

第三，检查你的Sass文件是否有不必要的复杂性。比如，过度嵌套、大量使用函数计算等都会拖慢编译速度。虽然你说拆分成了小文件，但如果每个小文件之间还有复杂的依赖关系，反而可能增加解析负担。

最后，如果以上方法都没法彻底解决问题，可以考虑在生产环境里绕过Vite的Sass处理，改用独立的Sass编译工具，比如直接用Dart Sass命令行工具生成CSS文件，然后让Vite只处理最终的CSS。这样可以把Sass编译的性能瓶颈从Vite中剥离出来。

总结一下，Vite在Sass处理上的性能劣势主要来自它的依赖解析机制和Sass插件的实现方式。通过切换到Dart Sass、启用fiber优化、简化Sass结构，或者在生产环境中独立编译Sass，应该能显著改善性能问题。希望这些方法能帮你解决问题，毕竟没人愿意卡在构建阶段浪费时间。

2026-02-19 22:05

程序猿贝贝 Lv1

前端这块遇到 Vite 处理 Sass 比 Webpack 慢的情况，其实挺常见的，但问题一般不在 Vite 本身，而是配置和底层依赖没对齐。

你提到用了 vite 的 sass 插件，但没说具体是哪个。Vite 原生支持 sass（也就是 Dart Sass），不需要额外插件，直接在项目里装 sass 包就行。如果你用了 vite-plugin-sass 这类第三方插件，反而可能多了一层包装，影响性能。

重点来了：Webpack 的 sass-loader 默认用的是同步编译，而且配合 cache-loader 或 thread-loader 能做到缓存和并行。而 Vite 在开发模式下是基于 ESBuild 预构建 + 原生 ESM 动态编译，Sass 文件每次修改都会触发重新解析，如果没有启用文件系统缓存，就会显得卡顿。

解决办法几个关键点：

第一，确认你用的是 sass（Dart Sass）而不是 node-sass，后者已经废弃，性能差还吃 CPU。执行：

npm install sass -D

然后 vite.config.js 里别加任何多余的 Sass 插件，Vite 会自动识别 .scss 文件。

第二，开启 Vite 的 fsCache 和 deps cache：

export default {

  server: {

    fs: {

      strict: false,

      allow: ['.']

    }

  },

  optimizeDeps: {

    include: ['sass']

  },

  build: {

    rollupOptions: {

      // 确保没有重复处理 CSS

    }

  },

  // 关键：启用实验性持久化缓存

  cacheDir: 'node_modules/.vite'

}

第三，生产构建慢是因为 Vite 默认不会像 MiniCssExtractPlugin 那样聚合 CSS，而是靠 Rollup 处理。你可以加个配置让 CSS 提取更高效：

build: {

  cssCodeSplit: true, // 按需拆分 CSS，别全打一起

  rollupOptions: {

    output: {

      assetFileNames: 'assets/[name][extname]'

    }

  }

}

最后一个小技巧：把大块的 Sass 文件顶部加上 @use 或 @import 的公共变量抽离出来，配合 Vite 的预编译能力，比如：

@use './variables' as *;

这样 Vite 在预构建时能更好缓存基础样式模块。

总结一下，不是 Vite 天生慢，而是你从 Webpack 那套缓存机制迁移过来时，没把 Vite 的缓存体系配好。把依赖换成纯 sass，去掉多余插件，开好 cacheDir，再加上合理的代码拆分，构建速度反而是比 Webpack 更快的。我这边好几个项目都是这么调下来的，从 5s 干到 2s 内。

2026-02-10 22:00