使用Webpack+SCSS加载图片时生成重复图片文件夹的问题

我来帮你拆解一下这个问题背后的原理，看完你就明白为啥会出现这种“写着原始路径却依赖生成文件夹”的情况了：

为什么SCSS里的原始路径没生效，反而要靠自动生成的img文件夹？ #

当Webpack处理你的SCSS文件时，会一步步解析url("../images/bg1.jpeg")这个引用：

• 第一步：Webpack会根据当前SCSS文件的相对位置，找到你源码里images/bg1.jpeg这个原始文件。
• 第二步：file-loader会把这个原始图片复制一份，放到你配置的/img/[name].[ext]路径下（也就是你看到的src里的img文件夹）。
• 第三步（最关键）：file-loader会偷偷把你SCSS里写的../images/bg1.jpeg路径，替换成生成后的/img/bg1.jpeg。

所以最终打包后实际生效的CSS代码里，背景图路径已经变成了指向img文件夹的版本——你写的原始路径只是Webpack用来找到源文件的“线索”，真正在浏览器里生效的是替换后的路径，这就是为啥删了img文件夹图片就加载失败。

为什么SCSS里必须写原始images文件夹的路径？ #

这是Webpack模块解析的规则决定的：Webpack在编译时，得从当前SCSS文件的位置出发，找到你引用的图片源文件。如果你直接写/img/bg1.jpeg，Webpack会一脸懵——因为此时img文件夹还没生成呢，它找不到任何文件，自然没法完成复制和路径替换的工作。

两个文件夹都要保留吗？ #

• 原始的images/文件夹：必须留着！这是你的源码仓库，Webpack每次编译都要从这里读取图片源文件，没了它，file-loader根本没东西可复制。
• 自动生成的img/文件夹：这是Webpack构建的产物，不用你手动维护。如果是开发环境，它可能临时出现在src里；如果是生产环境，你应该调整Webpack配置，让它输出到dist（或专门的构建输出目录）下，别和源码混在一起。下次构建时Webpack会自动重新生成，要是用了webpack-dev-server，甚至可能只在内存里处理，不会生成物理文件。

给你个优化配置建议 #

你可以调整file-loader的配置，让生成的图片输出到更合理的位置，避免污染源码目录：

{
  test: /\.jpe?g$|\.gif$|\.png$/i,
  loader: "file-loader",
  options: {
    name: "[name].[ext]",
    outputPath: "assets/img/", // 生成的图片会放到dist/assets/img/下
    publicPath: "/assets/img/" // 最终CSS里的路径会变成/assets/img/bg1.jpeg
  }
}

这样配置后，生成的图片会乖乖待在构建输出目录里，你的src目录也能保持整洁啦。

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