css-loader 和 less-loader 拖慢构建主因是串行单线程解析+AST转换且无默认缓存，每次JS修改都会重编译全部CSS/LESS；应启用cache-loader或Webpack 5文件系统缓存，并优化mini-css-extract-plugin配置及预编译静态样式。
为什么 css-loader 和 less-loader 会拖慢构建？
因为它们是串行、单线程执行的文本解析+AST转换操作，尤其在大型项目中处理几百个 LESS 文件时，less-loader 编译耗时常占总构建时间的 15%–20%。更关键的是：Webpack 默认不会缓存这些 loader 的中间结果，每次修改任意一个 JS 文件，所有 CSS/LESS 都会被重新解析一遍。
用 cache-loader 或 Webpack 5 原生 cache 拦住重复编译
不要只给 babel-loader 加缓存，css-loader 和 less-loader 同样需要 —— 但注意优先级和兼容性：
-
cache-loader适用于 Webpack 4/5，需显式插入 rule chain 前端：{ loader: 'cache-loader', options: { cacheDirectory: './node_modules/.cache/css' } } - Webpack 5 推荐直接启用顶层
cache: { type: 'filesystem' }，它自动为所有支持缓存的 loader（包括css-loader@6+、less-loader@8+）生效，无需手动加cache-loader - 若用了
postcss-loader，确保其postcss.config.js是纯 JSON/JS 导出，否则缓存会失效（因 Webpack 无法静态分析动态 require）
提取 CSS 时避免 mini-css-extract-plugin 成为新瓶颈
mini-css-extract-plugin 在生产环境提取 CSS 是必须的，但它本身会在 optimize-chunk-assets 钩子中同步执行压缩，容易阻塞构建流水线。常见误操作：
- 直接在
use里写['style-loader', 'css-loader']开发时没问题，但生产环境切到MiniCssExtractPlugin.loader后没关掉 source map，导致每个 CSS 文件都生成 .map 并写入磁盘 - 未配置
optimization.minimizer中的CssMinimizerPlugin并发数，默认为 1，大项目下 CSS 压缩变成单核瓶颈 - 错误地把
MiniCssExtractPlugin插件同时用于 dev 和 prod 环境，导致 HMR 失效（它不支持热替换）
预编译 LESS/SASS 到 CSS 再交给 Webpack
对变动极少的公共样式（如主题色变量、重置样式），跳过 Webpack 的 loader 链，改用独立构建步骤预编译：
立即学习“前端免费学习笔记（深入）”；
- 用
lessc src/styles/theme.less dist/css/theme.css提前生成，再通过import './dist/css/theme.css'引入 - 配合
watchOptions.ignored排除dist/css目录，防止 Webpack 扫描已编译文件 - 这样既减少 loader 数量，又让 Webpack 只处理真正需要模块化、作用域化的组件级样式
真正卡住构建的往往不是“有没有提取 CSS”，而是“每次改动都重跑整条样式链”。缓存策略、loader 顺序、插件使用时机这三点漏掉任何一个，优化就打折扣。
