rel="modulepreload"是专为ES模块设计的预加载机制，只下载并解析模块及其静态import依赖但不执行；而rel="preload"是通用预加载，不解析模块依赖、不校验CORS/MIME，需手动指定as属性。
rel="modulepreload" 是什么，和普通 preload 有什么区别
它不是给普通脚本用的，而是专为 type="module" 脚本设计的预加载机制。浏览器看到 ，会提前发起请求、下载并解析（但不执行），等真正遇到 <script type="module" src="app.js"></script> 时，可直接复用已解析的结果。
普通 rel="preload" 不带 type="module" 上下文，即使加了 as="script"，浏览器也不会按模块语义去解析——比如不会提前处理 import 依赖，也不会遵守模块的 CORS、MIME 类型校验逻辑。
- 模块预加载必须匹配实际模块脚本的
crossorigin属性（不匹配会导致重复下载或失败） -
href必须指向一个合法的模块脚本（服务端需返回Content-Type: application/javascript或text/javascript） - 不能用于内联
<script type="module">...</script>，只支持外部模块
为什么用了 modulepreload 还是触发了两次请求
最常见原因是 crossorigin 不一致。比如模块脚本写了 <script type="module" src="/a.js" crossorigin="anonymous"></script>，但预加载标签漏了 crossorigin 或写成了 crossorigin=""，浏览器会把它们视为两个不同资源。
- 预加载标签和真实 script 标签的
crossorigin值必须完全相同（anonymous/use-credentials/ 空值） - 如果脚本来自第三方域名，且未显式声明
crossorigin，浏览器默认按“无 CORS”处理；但一旦真实 script 加了crossorigin，预加载也必须同步加上 - Chrome DevTools 的 Network 面板里，看 Initiator 列：如果第二次请求的 Initiator 是
script而非link，基本就是没复用成功
modulepreload 能预加载 import() 动态导入的模块吗
不能直接预加载，但可以间接生效。浏览器对 import("/chunk.js") 的动态导入，本身不支持被 提前抓取——因为路径可能是运行时拼接的，静态分析不可靠。
不过，如果你在页面初始化阶段就明确知道要加载哪些动态模块，可以手动插入对应 ：
<link rel="modulepreload" href="/chunk1.js" as="script" crossorigin="anonymous"><link rel="modulepreload" href="/chunk2.js" as="script" crossorigin="anonymous">
然后在代码中调用 import("/chunk1.js")，只要 URL 字符串完全一致（包括查询参数），浏览器大概率会复用预加载结果。注意：
- 查询参数不同（如
/chunk.js?v=1vs/chunk.js?v=2）会被视为不同资源 - 使用
import.meta.url构造的相对路径，可能和预加载的绝对路径不匹配，导致失效 - Safari 目前对动态导入 + modulepreload 的复用支持不稳定，建议实测验证
要不要在所有模块脚本前都加 modulepreload
没必要，反而可能拖慢首屏。modulepreload 本质是「提前占用网络和解析资源」，但它不阻塞渲染，也不改变执行时机。滥用会导致：
- 抢占关键资源带宽（比如把本该优先加载的 CSS 或首屏图片的带宽占了）
- 解析大量暂时用不到的模块，增加内存压力
- 构建工具（如 Vite、Webpack）生成的入口 chunk 已经做了 code-splitting 和预加载提示，重复加可能冲突
推荐只对以下情况使用：
- 入口模块（
main.js）及其直接依赖（如框架核心、路由初始化模块） - 用户交互前大概率会用到的模块（如登录弹窗逻辑、富文本编辑器）
- 同一域名下延迟较高、且确定会被加载的模块（避免 TTFB 成为瓶颈）
预加载不是越多越好，关键是让浏览器更早知道「接下来要执行什么」，而不是把所有 JS 都提前拉下来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
