Webpack 核心概念之 Loader 详解：如何让 CSS 文件被打包识别

不少人在第一次使用 Webpack 时都会遇到同一个报错：在入口文件里写了一行 import './style.css'，执行打包命令后终端直接抛出异常，提示可能需要合适的 Loader 来处理这种文件类型。这个报错其实揭示了 Webpack 一个非常核心的设计理念：它天生只认识 JavaScript，任何非 JS 资源想进入打包流程，都必须先经过 Loader 的翻译。理解了这一点，CSS 打包的问题就迎刃而解了。

为什么 Webpack 需要 Loader 才能处理 CSS

Webpack 的本质是一个 JavaScript 模块打包器。在它的认知模型里，项目由一个个模块组成，而模块默认就是 JS 文件。当构建时遇到 CSS、图片、字体这类资源，Webpack 内置的解析器无法理解文件内容，于是会抛出类似 Module parse failed 的错误。

Loader 的作用就是在模块被加入依赖图之前，把非 JS 资源转换成 Webpack 能理解的 JavaScript 代码。以 CSS 为例，css-loader 会读取样式文件内容，把它包装成一个 JS 模块：这个模块导出的内容是一段字符串（样式本身），同时它还会解析 CSS 中的 @import 和 url() 引用，把被引用的文件也纳入依赖图，实现样式资源的模块化。

但 css-loader 只负责让 Webpack 认识 CSS，并不会让样式真正生效。样式要应用到页面上，还需要 style-loader 出场：它会在运行时把样式字符串动态插入一个 <style> 标签中。两者各司其职，缺一不可。

css-loader 与 style-loader 的基本配置

先安装依赖：

npm install css-loader style-loader --save-dev

然后在 webpack.config.js 中添加规则：

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  }
};

这里有一个非常容易踩坑的点：use 数组的执行顺序是从右到左、从下到上。也就是说，css-loader 先执行，负责解析 CSS 文件；style-loader 后执行，把 css-loader 处理后的结果插入页面。如果你把两个 Loader 的顺序写反了，打包就会直接报错。这个顺序本质上是由 Loader 的链式调用机制决定的——每个 Loader 接收上一个 Loader 的处理结果作为输入，因此排在前面的 Loader 负责收尾工作。

如果觉得数组形式容易搞混顺序，也可以写成对象形式并附加配置项：

use: [
  { loader: 'style-loader' },
  {
    loader: 'css-loader',
    options: {
      modules: true, // 开启 CSS Modules
      importLoaders: 1 // 让 @import 的资源也走后面的 loader
    }
  }
]

开启 CSS Modules 之后，类名会被编译成哈希值，有效避免样式冲突，这在多人协作的大型项目中非常实用。

样式抽离：mini-css-extract-plugin 的应用场景

style-loader 把样式内联到 JS 里，开发环境下热更新很快，体验很好。但生产环境这样做有问题：样式混在 JS 包里会导致文件体积膨胀，还会出现页面先渲染出无样式内容再闪一下的 FOUC 现象。生产构建通常改用 mini-css-extract-plugin 把 CSS 抽离成独立文件。

const MiniCssExtractPlugin = require('mini-css-extract-plugin');

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader']
      }
    ]
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'css/[name].[contenthash:8].css'
    })
  ]
};

注意这里的写法变化：原本 style-loader 的位置被 MiniCssExtractPlugin.loader 替代，两者的职责相同，只是输出方式不同——前者注入 <style> 标签，后者生成独立的 CSS 文件并通过 <link> 标签引入。抽离出的文件名带上 contenthash，有利于浏览器长效缓存。

此外，抽离出的 CSS 还可以用 optimize-css-assets-webpack-plugin 或 css-minimizer-webpack-plugin 做压缩，进一步减小体积。开发环境用 style-loader、生产环境用抽离方案，两套配置按环境切换是社区的主流做法。

扩展 Loader 链：处理 Sass、Less 与浏览器兼容

实际项目很少直接写原生 CSS，更多使用 Sass 或 Less 这类预处理器。此时需要在 Loader 链上再叠加一层：

module: {
  rules: [
    {
      test: /\.scss$/,
      use: [
        'style-loader',
        'css-loader',
        'sass-loader'
      ]
    }
  ]
}

执行顺序依然是自右向左：sass-loader 先把 SCSS 编译成标准 CSS，再交给 css-loader 解析依赖，最后由 style-loader 注入页面。如果 Less 项目，把 sass-loader 换成 less-loader 即可，思路完全一致。

很多初学者发现 CSS 里的 @import 语句引用的其他文件没有走 postcss-loader，导致自动补全浏览器前缀失效。解决办法是给 css-loader 配置 importLoaders，让被 import 的资源也回头走前面的 Loader：

use: [
  'style-loader',
  {
    loader: 'css-loader',
    options: { importLoaders: 2 }
  },
  'postcss-loader',
  'sass-loader'
]

postcss-loader 需要配合项目根目录下的 postcss.config.js 使用，常见的配置是集成 autoprefixer，根据 browserslist 声明自动添加兼容前缀。

最后提醒一点：Loader 的匹配依赖 test 正则表达式，处理 .css 和 .scss 要写成两条规则，或者用 /\.s?css$/ 合并匹配。同时注意排除 node_modules 时应使用 exclude 而不是简单地拆分规则，这样能让构建配置更清晰。掌握了 Loader 的链式机制，无论是样式、图片还是字体资源，处理思路都是一样的——找到合适的 Loader，按正确顺序串起来即可。

Webpack LoaderCSS打包前端工程化修改时间：2026-09-08 09:38:47