现代前端应用早已不是单个庞大的脚本文件能承载的了，代码分割、懒加载、微前端架构都对资源的网络加载提出极高要求。Webpack 5 没有在网络传输协议层面做文章，却在资源组织、缓存策略和模块共享机制上做了大量扎实的改进，使得应用在浏览器端获取代码与静态资源的效率得到显著提升。这些能力分散在 Module Federation、持久化缓存、资源模块等多个新特性中，下面逐一展开。
一、模块联邦：打破构建时依赖的运行时加载
模块联邦是 Webpack 5 中最具颠覆性的网络相关特性。它允许一个应用的构建产物暴露自身的一部分模块，供另一个完全独立的构建产物在运行时按需消费。这与传统的 npm 包发布或微前端中的 Script 标签加载完全不同——模块联邦构建的双方可以独立开发、独立部署，而共享模块在浏览器的运行时环境中被安全地加载并执行，同时具备完整的依赖共享与协商能力。
配置一个联邦提供方非常直观。在 webpack.config.js 中引入 ModuleFederationPlugin，声明暴露的模块和共享的依赖即可：
// 提供方 webpack.config.js
const { ModuleFederationPlugin } = require('webpack').container;
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'app_provider',
filename: 'remoteEntry.js',
exposes: {
'./Button': './src/components/Button',
},
shared: ['react', 'react-dom'],
}),
],
};消费方同样通过该插件指定远程模块地址，然后就可以像使用本地模块一样 import 远程暴露的组件：
// 消费方 webpack.config.js
new ModuleFederationPlugin({
name: 'app_consumer',
remotes: {
app_provider: 'app_provider@http://localhost:3001/remoteEntry.js',
},
shared: ['react', 'react-dom'],
});
// 在应用代码中
const RemoteButton = React.lazy(() => import('app_provider/Button'));这种按需网络加载的背后，Webpack 在消费方的构建产物中并不会包含提供方的模块代码，而是在运行时通过动态 <script> 加载 remoteEntry.js，解析出模块声明，再结合 shared 配置协商依赖版本。如果消费方已经加载了满足要求的依赖，远程模块就会直接复用，避免重复加载相同库。这种机制天然适合微前端场景下子应用之间的组件复用，也极大减少了主应用的初始包体积，让网络请求只发生在真正需要某个模块的时刻。
需要留意的是，模块联邦仍然依赖 HTTP 协议拉取远程入口文件，生产环境需要确保入口文件的缓存策略合理（比如配置较短的缓存时间或使用协商缓存），否则版本更新后消费方可能仍在加载旧模块。另外，跨域问题也需要在提供方服务器上做好 CORS 配置，保证 remoteEntry.js 能被跨域加载。
二、确定性与持久化缓存：让网络请求物尽其用
对网络加载而言，最极致的优化就是不请求——利用浏览器缓存。Webpack 5 在缓存策略上做了两件重要的事：引入确定性的模块和 chunk ID，以及提供基于文件系统的持久化构建缓存。前者直接提升生产环境资源的长效缓存能力，后者则通过加速构建间接减少了因频繁构建而造成缓存更新滞后的风险。
以前，Webpack 使用自增的数字作为模块 ID，代码顺序稍有变动就可能导致 chunk 内容变化，即使业务逻辑未改，生成的文件名哈希也会改变，从而使浏览器缓存失效。Webpack 5 默认启用 optimization.moduleIds: 'deterministic' 和 optimization.chunkIds: 'deterministic'。它们基于模块路径等元数据生成固定的哈希，因此模块增删不会大范围影响无关模块的 ID，chunk 内容稳定性大幅提升。配合内容哈希文件名，浏览器就可以长期缓存那些未真正变更的资源，二次访问时网络请求数量降到最低。
配置也极其简单，甚至无需手动设置，生产模式下的默认值已经是确定性的：
module.exports = {
// 生产模式自动启用
optimization: {
moduleIds: 'deterministic',
chunkIds: 'deterministic',
runtimeChunk: 'single', // 将 runtime 代码独立为稳定文件
},
output: {
filename: '[name].[contenthash].js',
},
};通过独立的 runtimeChunk，Webpack 的运行时逻辑（用于模块加载的引导代码）被抽离成单独文件。这部分代码往往受构建影响频繁变化，独立出来后，对业务 chunk 的内容哈希几乎不再干扰，从而让那些体积较大的业务 chunk 更长久地待在浏览器缓存中。网络层面，用户只会重新下载真正变化了的 chunk，对于网络带宽和加载延迟的改善非常显著。
三、资源模块：减少额外 Loader 与请求开销
在 Webpack 4 时代，处理图片、字体这类静态资源通常需要使用 file-loader、url-loader 等 loader，配置繁琐且会增加网络请求的复杂度。Webpack 5 内置了四种资源模块类型：asset/resource、asset/inline、asset/source 和 asset，完全替代了这些 loader 的角色，让资源处理更高效、更可控。
asset 类型最为灵活，它可以自动在导出文件 URL 和导出 Data URI 之间选择，阈值可配。例如，小于 8KB 的图片会被内联为 Base64，减少一次 HTTP 请求；大于阈值的则输出为独立文件，让浏览器可以并行下载和缓存。这样一来，网络请求数量与资源体积到得到了平衡。
module.exports = {
module: {
rules: [
{
test: /.(png|jpg|gif)$/i,
type: 'asset',
parser: {
dataUrlCondition: {
maxSize: 8 * 1024, // 8KB
},
},
generator: {
filename: 'images/[name].[hash][ext]',
},
},
{
test: /.(woff|woff2|eot|ttf|otf)$/i,
type: 'asset/resource',
generator: {
filename: 'fonts/[name].[hash][ext]',
},
},
],
},
};这段配置不仅消除了第三方 loader 依赖，也让资源的输出路径和命名更直观。从网络角度审视，内联小资源虽然减少了请求，但却增加了父级文件的体积，可能拖慢首次解析。Webpack 5 允许开发者根据实际网络环境和应用特点，针对不同资源类型制定细粒度的内联策略，既避免了过度碎片化的小文件请求，又防止了 Data URI 过于臃肿。
此外，资源模块与代码分割和预加载（/* webpackPreload: true */）等机制配合使用时，能够实现更精细的优先级控制。例如对首屏关键图片使用 asset/inline 直接嵌入，对于非首屏大图交由 asset/resource 配合 HTTP/2 服务器推送或预加载，整体感知速度会进一步提升。
四、更智能的代码分割与网络请求优化
网络层面的性能离不开代码分割。Webpack 5 对 SplitChunksPlugin 的默认配置进行了调整，并增加了 chunks: 'async' 下默认拆分的强度，同时加强了对共享模块的最小引用阈值和体积阈值控制，避免产生过多微小的 chunk。过多的 chunk 会导致网络请求数量膨胀，在非 HTTP/2 环境下反而降低加载性能。Webpack 5 更聪明的默认值帮助开发者少踩坑。
一个典型场景是提取公共依赖。通过 cacheGroups 把 react、lodash 等稳定库抽成单独的 vendor chunk，这些 chunk 可以享受长期缓存。结合 contenthash 命名，它们只在依赖版本升级时才会重新下载。而异步加载的业务逻辑则按路由或功能拆分，让用户只加载当前所需。
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\/]node_modules[\/]/,
name: 'vendors',
chunks: 'all',
},
},
},
},Webpack 5 还内生支持了模块的预取和预加载指令。在 import() 语法中使用魔法注释 /* webpackPrefetch: true */ 可以让 Webpack 在页面空闲时预先拉取将来可能用到的模块，网络请求以低优先级在后台完成，不影响当前页面的交互。对于用户可能快速点击的下一个页面，这种预取技术几乎可以消除网络延迟带来的白屏时间。
综合来看，Webpack 5 在网络相关特性上并没有发明新的传输协议，而是通过模块联邦扩展了运行时共享模型，通过确定性和持久化缓存巩固了缓存友好度，通过资源模块简化并优化了资源加载，最后通过更智能的代码分裂与预取策略让网络请求的编排更符合实际使用场景。这些特性相互配合，构成了一个高效的网络资源加载体系，值得前端团队在生产项目中深入实践。