link rel="prefetch"不是加速当前页的工具，仅在onload后空闲时低优先级预取下页资源；看不到Network请求主因是触发条件未满足：Chrome默认过滤该类型、资源强缓存、未触发onload、用户跳失、跨域或as属性错误。
link rel="prefetch" 不是用来加速当前页的，它只在页面 onload 后、浏览器空闲时，低优先级下载下一页可能用到的资源——写对了也不保证执行，写错了基本没反应。
为什么写了 link rel="prefetch" 却看不到 Network 请求
这不是代码写错，而是触发条件根本没满足：
- Chrome DevTools 默认过滤掉
prefetch类型请求，必须手动勾选 “prefetch” 或清空所有过滤器才能看到 - 资源已被强缓存（如
Cache-Control: immutable），浏览器直接从磁盘读，根本不发新请求 - 页面还没触发
onload（比如有长任务阻塞主线程），或用户已跳转/关闭标签页，prefetch 被中止 - URL 跨域（协议、域名、端口任一不同），浏览器静默忽略，Network 里连
OPTIONS都没有 -
as属性缺失或错误（比如写成as="fetch"），导致降级为as="document"，甚至被忽略
link rel="prefetch" 必须满足的三个硬性条件
缺一不可，否则等于白写：
- 必须放在
<head>中，且 HTML 解析时已存在 DOM —— 动态插入（如document.head.appendChild(link)）大多无效 - 目标 URL 必须同源，跨域请求不会发起（连 DNS 查询都不会触发）
- 浏览器必须处于空闲状态：无高优先级请求、CPU/网络负载低、页面未卸载
典型正确写法：<link rel="prefetch" href="/js/detail.chunk.js" as="script">；as 值必须准确对应资源类型（script、style、document、image 等），不能乱填。
立即学习“前端免费学习笔记（深入）”；
和 preload、preconnect 混用时的关键区别
三者解决的问题完全不同，不能互相替代：
-
rel="preload"是高优先级加载当前页必用资源，会抢占带宽，页面跳转后即失效 -
rel="prefetch"是低优先级、空闲时投机下载下一页资源，进的是 HTTP 缓存，跨页面复用 -
rel="preconnect"只做 TCP+TLS 连接预热，适合高频跨域 API 域名，但必须加crossorigin才在 Safari/旧 Chrome 生效
例如加载 https://api.example.com/data.json，最优组合是：<link rel="dns-prefetch" href="https://api.example.com"> + <link rel="preconnect" href="https://api.example.com" crossorigin>；别加 prefetch，除非你确定用户下一步 80% 会点某个按钮触发这个请求。
真正容易被忽略的一点：prefetch 不提供任何 JS 可读接口，它不执行脚本、不解析 HTML、不触发 fetch，只是把文件丢进 HTTP 缓存。想“预取数据”，得换方案——比如路由切换前用 fetch() 预加载 JSON，或用 import() 动态导入模块。
