在单页应用越来越复杂的今天，模块的按需加载已经成为标配，但仅仅做到按需加载还不够。如果用户点击某个按钮时才开始下载对应的 chunk，网络请求的延迟依然会让交互显得卡顿。Webpack 5 对 Preload 和 Prefetch 提供了开箱即用的支持，通过简单的注释语法就能告诉浏览器提前获取资源，让动态导入的模块在真正需要时已经躺在缓存里。本文将从原理、用法和实践三个层面，完整讲清楚这套机制怎么用、什么时候用以及用错了会怎样。
一、Preload 和 Prefetch 的底层原理与区别
要理解这两个特性，首先要从浏览器的资源加载机制说起。Webpack 在打包时如果发现动态导入语句带有特殊注释，会在生成的 HTML 或者运行时的 chunk 加载逻辑中，自动向文档的 head 里注入 <link> 标签。对于 Preload，注入的是 <link rel="preload">，它告诉浏览器这是一个当前导航一定会用到的资源，应当以较高优先级立刻开始下载；对于 Prefetch，注入的是 <link rel="prefetch">，它表示这个资源未来可能会用到，浏览器会在空闲时间以最低优先级悄悄下载。
两者的核心差异可以概括为三个维度。第一是优先级：Preload 的资源会参与当前页面的关键渲染路径竞争，权重高；Prefetch 则完全不干扰当前页面的加载，只在网络空闲时执行。第二是使用时机：Preload 适合当前页面确定要使用的模块，比如首屏渲染后立刻就要挂载的组件；Prefetch 适合用户下一步可能跳转的页面，比如首页的登录弹窗，用户可能点开也可能不点。第三是兼容性与带宽消耗：Prefetch 下载的资源如果始终没被使用，就白白消耗了用户的流量，在移动端场景需要谨慎评估。
从 Webpack 内部实现看，这个功能由 webpack@5 内置的 RuntimeChunk 加载器配合 HTML 注入完成。当浏览器解析到带 rel="preload" 的 link 标签时，会提前发起请求并把响应存入 HTTP 缓存，等到 Webpack 的运行时真正执行 import() 时，直接命中缓存，省去了整个网络往返的时间。
二、在 Webpack 5 中的具体用法与代码示例
Webpack 5 的用法非常简洁，直接在动态导入语句前添加魔法注释即可。先看一个基本的例子，对比普通导入、Preload 导入和 Prefetch 导入三种写法：
// 普通动态导入：点击时才开始下载 chunk
document.getElementById('btn').addEventListener('click', () => {
import('./components/Modal').then(({ default: Modal }) => {
Modal.open();
});
});
// Prefetch：浏览器空闲时提前下载，点击时直接从缓存读取
document.getElementById('btn2').addEventListener('click', () => {
import(/* webpackPrefetch: true */ './components/Modal').then(({ default: Modal }) => {
Modal.open();
});
});
// Preload：与父 chunk 并行下载，优先级高
import(/* webpackPreload: true */ './components/Header');
上面代码中，第一种写法是最常见的按需加载，用户体验取决于网络速度；第二种加上 webpackPrefetch: true 后，Webpack 会在页面加载完成后通过注入的 link 标签预取 Modal 组件的 chunk，用户点击按钮时模块已经在缓存中，弹窗几乎是瞬时出现；第三种 Preload 写法适合当前页面渲染必需的模块，它会在父 chunk 加载的同时并行请求，而不是等待空闲。
需要注意 chunk 的拆分方式会影响效果。如果你在配置中使用了 splitChunks，公共依赖会被抽取成独立的 chunk，此时 Prefetch 注释会作用在整个 chunk 依赖链上。下面是一个结合 splitChunks 的配置示例：
// webpack.config.js
module.exports = {
optimization: {
splitChunks: {
chunks: 'all',
cacheGroups: {
vendor: {
test: /[\\/]node_modules[\\/]/,
name: 'vendors',
chunks: 'all'
}
}
}
}
};
另外，Prefetch 注释还可以结合模块合并使用。如果多个入口都 Prefetch 同一个模块，Webpack 会自动去重，只在页面中注入一次 link 标签，不会造成重复请求。你可以通过浏览器开发者工具的 Network 面板验证效果：启用了 Prefetch 的资源会显示 Priority: Lowest，并且在页面加载完成后才发起。
三、常见误用场景与性能优化建议
第一个常见的误用是对大量模块滥用 Prefetch。有些开发者图省事，把所有路由页面的组件全部加上 Prefetch，结果用户一进入首页，浏览器就疯狂下载几十个 chunk，移动端用户的流量瞬间被消耗殆尽，同时大量并发的空闲请求也可能挤占其他正常资源的带宽。正确的做法是基于用户行为数据做判断，只对访问概率高的下一级页面做 Prefetch，比如从商品列表页 Prefetch 详情页的组件就比较合理。
第二个误区是混淆 Preload 和 Prefetch 的适用场景。Preload 会提升资源优先级，如果你把一个用户大概率不会用到的模块标记为 Preload，等于人为加剧了首屏关键资源的竞争，反而拖慢首屏速度。一个简单的判断标准：当前页面渲染完成后立刻就要执行的代码用 Preload，未来某个交互之后才可能执行的代码用 Prefetch。
第三个注意点涉及 HTTP 缓存头。Prefetch 下来的资源能否被后续的 import() 命中，取决于资源的缓存策略。如果服务器返回的响应头中 Cache-Control 设置为 no-store，那么预取的收益会大打折扣。建议为 chunk 文件设置合理的强缓存策略，例如：
// Node.js Express 中为带 hash 的静态资源设置一年强缓存
app.use('/dist', express.static(path.join(__dirname, 'dist'), {
immutable: true,
maxAge: '1y'
}));
最后，配合 Chrome 的 Lighthouse 工具可以量化优化效果。在实践中，合理使用 Prefetch 通常能把交互等待时间压缩到几十毫秒以内，因为模块执行只需要 CPU 计算，网络耗时已经在前面的空闲时间被消化掉了。同时也要记得定期审查预取清单，随着业务迭代，某个曾经高频访问的页面可能已经无人问津，对应的 Prefetch 注释应该及时移除，保持加载策略与真实用户行为的一致性。