为何要用Webpack编译SASS并加载CSS？生产环境需插件提取似绕圈

这个问题问得特别戳中痛点——很多刚接触Webpack的同学都会疑惑：打包JS也就算了，为啥连CSS都要交给它处理？到生产环境还要费劲提取成单独文件，这不又回到以前用<link>引入的老路了吗？其实这背后藏着不少实用的考量，咱们慢慢说：

• 模块化CSS，告别全局污染
  传统的CSS写法里，所有样式都是全局的，很容易出现类名冲突、样式意外覆盖的问题。用Webpack处理的话，你可以把CSS和对应的组件/模块绑定在一起，比如在Vue组件或者React组件里直接import './Card.scss'，让样式和组件的生命周期绑定，不仅维护起来更清晰，还能从根源上减少全局样式污染。而且SASS的嵌套、变量、混合宏这些特性，Webpack能直接帮你编译处理，不用额外单独跑编译脚本，一套流程搞定所有样式预处理。

• 统一管理所有资源依赖
  你的SASS里肯定会引用背景图、字体这些资源吧？用Webpack处理的话，它会自动帮你处理资源路径、压缩优化，甚至把小图片转成base64嵌入样式里。要是用传统的<link>方式，你得手动维护这些资源的路径，一旦项目结构变动，改起来简直是灾难。Webpack把JS、CSS、图片、字体所有资源都当成模块来处理，统一管理依赖，整个项目的构建流程是一致的，不用分开维护多个构建脚本。

• 开发体验直接拉满
  开发阶段用style-loader把CSS注入到页面里，配合Webpack的热模块替换（HMR），你修改SASS后浏览器会实时更新样式，完全不用手动刷新页面，开发效率提升不是一点半点。而传统方式改完CSS还得手动刷新，体验差远了。

那为啥生产环境还要提取CSS成单独文件？这其实是性能优化的刚需：
如果把CSS打包到JS里，浏览器得先加载完JS、执行JS才能把样式插入页面，这就会导致页面加载时出现“无样式内容闪烁”（FOUC）的问题，用户体验很糟糕。单独提取CSS文件的话，浏览器可以并行加载JS和CSS，而且CSS文件还能单独被浏览器缓存，下次用户访问时不用重新加载，加载速度更快。

说白了，这不是绕回原点，而是在传统<link>引入的基础上，结合了现代前端的模块化、统一构建、开发体验优化这些需求，生产环境提取CSS则是平衡开发效率和用户体验的折中方案。

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