有没有遇到过这样的处境：同事提交了一个特性分支，你想快速看一眼变更是否合理，结果光是本地构建就花了 5 分钟，等环境跑起来，思路早已被打断。而且一些历史项目里 Webpack 配置层层嵌套，想确认某个 loader 到底处理了哪些文件，还得对照着解析后的配置大海捞针。Webpack 5 的发布并不只是升级了几个 API，它在提升构建速度和降低认知负荷上的改进，恰好击中了代码审查中的这些真实痛点。
持久化缓存：让二次审查的构建等待归零
代码审查通常不是一锤子买卖，往往需要来回几轮修改、验证。如果每次 checkout 代码后都要重新编译整个项目，工程师宝贵的注意力会被反复打断。Webpack 5 引入了文件系统级别的持久化缓存，可以将首次构建的产物和模块依赖信息序列化到磁盘，后续构建只需处理变更部分，其余模块直接从缓存读取。
开启持久化缓存的配置非常简单，只需要在 webpack.config.js 中设置 cache.type 为 'filesystem'。Webpack 会在项目目录下生成一个 .cache 缓存文件夹，存储编译过程中的模块和 chunk 信息。即使重启计算机，缓存依然有效，因为 key 是根据文件内容哈希计算的，只要源码没变，缓存就不会失效。
对于代码审查者来说，这一特性意味着：拉取一个包含数百个模块的 PR 分支后，初次构建慢一些可以接受；但当复审者同时处理多个分支，或者需要反复在分支间切换比对效果时，缓存带来的性能提升立竿见影。根据实际项目规模，二次构建时间可以从分钟级降至 2~5 秒，几乎不会打断审查节奏。团队还可以将 .cache 目录加入 .gitignore，避免缓存文件污染仓库，让每个开发者本地都有独立的加速体验。
// webpack.config.js
module.exports = {
cache: {
type: 'filesystem', // 将缓存写入磁盘
buildDependencies: {
config: [__filename] // 当配置文件变化时，缓存失效
}
},
// ...其它配置
};
需要注意的是，持久化缓存并非银弹，在 CI 环境中由于每次都是全新拉取分支，缓存文件并不存在，仍需要一次完整构建。但代码审查大多发生在本地环境，这正是缓存发挥威力的主场。此外，某些 loader 可能产生不稳定的输出（如根据时间生成版本号），建议审查相关配置时额外关注 cache.buildDependencies 和 cache.version 的设置，确保缓存按预期失效。
模块联邦：让微前端代码审查不再依赖远程环境
单体应用拆分后，代码审查往往面临一个尴尬的局面：一个团队的模块变更，可能需要另一个团队启动对应的宿主应用才能完整验证。在没有模块联邦之前，常见的做法是本地启动多个服务，或者发布到测试环境后交叉审查，流程冗长且互相阻塞。
Webpack 5 的模块联邦允许应用在运行时动态加载其它应用的模块，而该模块的开发和构建完全独立。这让代码审查可以直接在本地模拟真实集成场景，不需要等待对方部署。举例来说，团队 A 负责一个公共组件库，通过模块联邦暴露出来；团队 B 在自己的应用里远程加载该组件。当团队 A 提交了一个关于某个组件的 PR 后，团队 B 的审查者只需在自己的配置里将远程入口指向 A 的本地开发服务器，就能立刻看到变更后的效果。
这种审查模式大幅减少了跨团队联调的等待成本。模块联邦通过 exposes 和 remotes 两个配置项声明暴露者和消费者。审查者甚至可以在本地动态切换远程地址，比如通过环境变量控制，方便对比新旧版本。以下是一个简单的远程引入示例，审查者可以快速将远程应用指向 PR 作者的本地分支进行验证，而不需要重新构建整个宿主应用。
// 团队 B 的 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'host',
remotes: {
// 远程模块 app_components，运行时从指定地址加载
app_components: process.env.REVIEW_MODE
? 'app_components@http://localhost:3002/remoteEntry.js'
: 'app_components@https://cdn.ippipp.com/remoteEntry.js'
}
})
]
};
代码审查者在拉取团队 A 的 PR 后，只需在终端执行 REVIEW_MODE=true npm start，就能让宿主应用连接到本地运行的团队 A 模块，看到实时的交叉效果。这种做法实际上把跨应用联动测试的成本从“部署 + 通知”降低到了“切换环境变量”，让审查真正聚焦在业务逻辑和交互是否符合预期上。
资源模块与确定性 ID：提升配置可读性，减少审查模糊地带
代码审查不光看业务代码，像 Webpack 配置、规则链等基础设施也是审查的一部分。Webpack 4 时期，处理图片、字体等资源通常需要配合 file-loader 或 url-loader，配置形式比较隐晦，审查者需要同时理解多个 loader 的协作关系，一不小心就会忽略文件输出路径或命名冲突的风险。
Webpack 5 内置的资源模块（Asset Modules）用四种类型替代了这些 loader：asset/resource（对应 file-loader）、asset/inline（对应 url-loader）、asset/source（对应 raw-loader）以及 asset（自动选择）。配置一下子变得一目了然：审查者看到 type: 'asset/resource' 就知道这会输出单独文件，看到 type: 'asset/inline' 就知道会转为 data URI 内联。这种显式声明**减少了配置的隐式依赖，让团队在审查规则时不再需要回忆 loader 间的优先级和默认行为。
另一个容易被忽视但影响审查体验的特性是确定性模块 ID。在 Webpack 4 中，模块 ID 默认是递增的数字，每次构建顺序变化都会导致输出文件哈希完全不同，这让审查者在对比构建产物的 diffs 时经常被无意义的哈希变化淹没。Webpack 5 将 optimization.moduleIds 的默认值改为 'deterministic'，模块 ID 根据文件相对路径生成，业务模块的 ID 在多次构建间保持稳定。这样，代码审查时如果需要人工核查构建出的 chunk 文件列表或大小变化，可以清楚地看到真正新增或修改的模块，而不是一堆无差别的哈希突变。
// webpack.config.js
module.exports = {
module: {
rules: [
{
test: /.png$/,
type: 'asset', // 根据大小自动选择 resource 或 inline
parser: {
dataUrlCondition: {
maxSize: 8 * 1024 // 8KB 以下内联
}
}
},
{
test: /.svg$/,
type: 'asset/resource' // 始终输出单独文件
}
]
},
optimization: {
moduleIds: 'deterministic', // 显式声明，保持模块 ID 稳定
chunkIds: 'deterministic' // 同样稳定 chunk ID
}
};
上述配置使得审查者在浏览 Webpack 相关改动时，能够快速界定资源处理策略，并且不再被莫名其妙的哈希差异所迷惑。当团队把这类基础设施改动纳入 PR 时，清晰的配置语义会让审查流程更加顺畅，避免因工具链理解偏差导致的沟通内耗。
Webpack 5 的这些新特性并没有颠覆构建工具的本质，却从执行效率、跨应用协作和配置可读性三个维度为代码审查扫清了常见的障碍。当构建速度不再成为痛点，远程模块可以随心切换，配置规则变得易于理解，开发者才更有可能把精力投入到真正需要批判性思维的业务逻辑与架构设计上。如果你的团队还在为代码审查中的等待和干扰头疼，不妨从以上三点入手，让 Webpack 5 为审查工作流注入一些确定性。