CSS和Less打包慢的常见瓶颈在于加载链路长、解析范围过大及缓存未启用：未用include/exclude限制loader作用域导致扫描node_modules；less-loader与css-loader重复解析@import/url()；未启用Webpack 5+ filesystem缓存；MiniCssExtractPlugin在开发环境引入IO开销；javascriptEnabled:true使less-loader执行JS逻辑导致缓存失效。
为什么CSS和Less打包慢？常见瓶颈在哪
Webpack处理CSS/LESS慢，通常不是因为语法本身，而是加载链路长、解析范围大、缓存未生效。比如less-loader依赖Node.js运行时编译，css-loader要解析@import和url()，style-loader还要注入DOM——每一步都可能被拖慢。更常见的是：没限制include导致扫描整个node_modules，或没启用缓存让每次构建都重跑一遍。
缩小loader作用范围：include + exclude必须写全
默认test: /\.less$/会匹配项目下所有.less文件，包括node_modules里第三方组件的样式（比如antd自带的less），这些文件既不需要你改，也不该被反复编译。
-
include只指向你的源码目录：include: path.resolve(__dirname, 'src') -
exclude显式排除node_modules：exclude: /node_modules/ - 如果用了CSS预处理器（如
less），确保less-loader前的css-loader也加了相同include/exclude，否则它仍会遍历所有CSS引用
错误示例：use: ['css-loader', 'less-loader']但没配include；正确写法应为每个loader单独声明作用范围，或统一套在rule顶层。
启用持久化缓存：filesystem cache对CSS类资源最有效
Webpack 5+的cache.type = 'filesystem'对CSS/LESS这类文本型资源收益明显——编译后的CSS AST、解析后的@import依赖树都能缓存，下次启动直接复用。
立即学习“前端免费学习笔记（深入）”；
- 务必指定
cache.cacheDirectory，避免默认缓存在node_modules导致权限问题 -
buildDependencies.config要包含__filename和所有配置文件路径，否则改了webpack.config.js或less.config.js缓存不会失效 - 如果项目用了
postcss插件（如autoprefixer），它的配置变动也要加入buildDependencies，否则缓存可能过期
示例配置片段：
cache: {<br> type: 'filesystem',<br> cacheDirectory: path.resolve(__dirname, '.webpack-cache'),<br> buildDependencies: {<br> config: [__filename],<br> postcss: [path.resolve(__dirname, 'postcss.config.js')]<br> }<br>}
避免多层loader串联时重复解析
一个.less文件常经过less-loader → css-loader → MiniCssExtractPlugin.loader三道处理。其中css-loader会再次解析url()和@import，而less-loader其实已经做过一次——这属于冗余工作。
- 把
css-loader的import和url解析关掉：{ import: false, url: false }，交由less-loader统一处理 - 如果用了
postcss-loader，确保它放在css-loader之后、MiniCssExtractPlugin.loader之前，且不重复处理已解析的URL - 开发环境慎用
MiniCssExtractPlugin，它会强制走文件系统IO；改用style-loader配合HMR，热更新更快
容易忽略的一点：当less-loader开启javascriptEnabled: true时，它会执行内联JS逻辑（比如动态生成变量），这会让缓存失效——除非你确定需要，否则关掉它。
