Webpack v5.108.4 是一个补丁版本，变化不大，但方向很明确：减少 CSS 解析阶段的无效工作，让非 CSS Modules 场景跑得更快。对日常项目来说，这类更新通常不会改变配置写法，却可能让构建链路少做一批没有产出的 AST 和 token 处理。
这次补丁主要动了哪里
这次发布的核心变化集中在 CSS 解析性能上，尤其是“非 CSS Modules”的代码路径。
在很多项目里，CSS 文件只是作为全局样式、组件样式或第三方库样式被打进 bundle，并不依赖 CSS Modules 的局部类名映射能力。Webpack 过去在解析这些 CSS 时，仍可能构建一些后续不会使用的选择器 AST 节点。v5.108.4 通过跳过这类未使用节点，减少了 CPU 和内存消耗。
另一个优化是丢弃无法读取的 value token。CSS 解析器在面对某些值片段时，如果这些 token 后续没有可用信息，继续保留它们只会增加解析负担。补丁把这部分无效标记丢掉，让非 CSS Modules CSS 的处理路径更短。
这不是“换打包模型”的大版本升级，而是典型的工程型优化：不改变用户 API，压掉热路径里的多余对象和分支。
为什么非 CSS Modules 值得单独优化
CSS Modules 和普通 CSS 的需求不同。
CSS Modules 需要理解选择器里的局部类名，并生成 JavaScript 可消费的映射关系，例如：
.button {
color: red;
}
会在 JS 里变成类似：
import styles from "./button.module.css";
console.log(styles.button);
普通 CSS 则不需要这层映射。它更关心依赖收集、资源引用和最终注入或抽取，比如：
import "./global.css";
因此，如果普通 CSS 仍走了过多 CSS Modules 才需要的解析动作，构建就会做额外工作。v5.108.4 的优化点就在这里：对非 CSS Modules 路径少构建、少保留、少传递。
可以这样升级并做一次本地对比
如果你的项目已经在 Webpack 5 上，通常可以直接升级补丁版本。下面示例使用 npm，你可以按项目实际包管理器替换为 pnpm 或 yarn。
npm install --save-dev webpack@5.108.4 webpack-cli@latest
npx webpack --version
为了观察构建耗时，可以临时加一个最小配置，并打开构建 profile。假设项目入口是 src/index.js，可以这样实践：
// webpack.config.js
const path = require("path");
module.exports = {
mode: "production",
entry: "./src/index.js",
output: {
path: path.resolve(__dirname, "dist"),
filename: "bundle.js",
clean: true
},
module: {
rules: [
{
test: /\.css$/i,
type: "css/auto"
}
]
},
experiments: {
css: true
},
profile: true,
stats: {
preset: "normal",
timings: true,
modules: true
}
};
然后准备一个普通 CSS 入口：
// src/index.js
import "./global.css";
console.log("webpack css parse test");
/* src/global.css */
:root {
--brand-color: #2454ff;
}
body {
margin: 0;
color: var(--brand-color);
font-family: system-ui, sans-serif;
}
.card > h2 + p {
line-height: 1.6;
}
运行构建并输出 stats 文件：
npx webpack --config webpack.config.js --json > stats-webpack-5-108-4.json
如果你想和旧补丁版本对比，可以在一个干净分支上安装旧版本，再生成一份 stats：
npm install --save-dev webpack@5.108.3
npx webpack --config webpack.config.js --json > stats-webpack-5-108-3.json
npm install --save-dev webpack@5.108.4
npx webpack --config webpack.config.js --json > stats-webpack-5-108-4.json
再用一个小脚本看总体构建时间。注意：不同机器、缓存状态和依赖规模会影响结果，建议多跑几次取中位数。
// compare-webpack-stats.js
const fs = require("fs");
for (const file of process.argv.slice(2)) {
const stats = JSON.parse(fs.readFileSync(file, "utf8"));
console.log(`${file}: ${stats.time}ms`);
}
node compare-webpack-stats.js stats-webpack-5-108-3.json stats-webpack-5-108-4.json
如果你的项目大量引入普通 CSS、第三方 UI 库 CSS、设计系统样式文件，这类解析优化更容易体现出来。小型项目可能只看到几十毫秒以内的波动，这也正常。
<base href> 相关变化要留意
摘要中还提到，Webpack 会根据文档中的 <base href> 解析相关 HTML 地址。这类变更通常会影响浏览器环境下 URL 的解释方式，尤其是页面设置了 base 路径时。
可以用下面这个最小 HTML 片段检查你的页面假设：
<!doctype html>
<html>
<head>
<base href="/app/">
</head>
<body>
<script src="assets/main.js"></script>
</body>
</html>
在浏览器里，assets/main.js 会按 /app/assets/main.js 解析，而不是站点根目录下的 /assets/main.js。如果你的应用部署在子路径，比如 /console/、/admin/，需要确认 Webpack 输出资源路径、HTML 模板和运行时 public path 是否一致。
一个常见配置是显式声明 publicPath：
// webpack.config.js
module.exports = {
output: {
publicPath: "/app/"
}
};
如果项目通过 CDN 发布静态资源，则不要让 <base href> 和 CDN 地址各说各话。否则脚本、图片、动态 import chunk 的解析路径可能出现偏差。
升级建议
这次版本适合 Webpack 5 用户按补丁升级处理，尤其是 CSS 体量较大的前端仓库、组件库构建和后台管理系统。
升级前建议做三件事：
- 跑一次完整构建，确认 CSS、图片、字体和动态 chunk 路径没有变化。
- 如果页面使用
<base href>，在本地或预发环境检查子路径部署。 - 对构建耗时做多次采样，不要只看一次冷启动结果。
边界也很清楚：这是解析层面的补丁优化，不会把一个配置混乱的构建系统瞬间变快。真正的大头仍可能在 Babel、TypeScript、压缩、source map 或 loader 链路里。但这种小版本值得跟进，因为它减少的是每次构建都会重复支付的成本。