rel="prefetch" 对图标无效，浏览器自动处理<link rel="icon">；它仅适用于同源、静态声明、onload后空闲时预加载下一页HTML等高概率资源。
rel="prefetch" 不是用来预加载图标的——它根本不会触发图标加载，也不该这么用。
浏览器对 <link rel="icon"> 的处理是独立且自动的，prefetch 对它完全无效。如果你在 <head> 里写了 <link rel="prefetch" href="/favicon.ico">，浏览器大概率会忽略，或者即使下载了也不会用于显示图标。真正起作用的只有一行：<link rel="icon" href="/favicon.ico">，且必须放在 <head> 中、尽早出现。
rel="prefetch" 适合预加载哪些资源
它只对用户下一步极可能访问的内容有意义，比如：
- 下一页 HTML（如
/product/123.html） - SPA 中即将进入的路由 JS chunk（如
/js/profile.chunk.js） - 高点击率商品页的 CSS（如
/css/detail.css）
这些资源要满足三个硬性条件才可能被真正拉取：
立即学习“前端免费学习笔记（深入）”；
-
<link>必须在初始 HTML 的<head>中静态存在，不能通过 JS 动态插入 -
href必须是同源 URL（协议、域名、端口全一致），跨域会被静默丢弃 - 页面已触发
onload，且浏览器当前空闲（无高优请求、CPU/网络负载低）
为什么你总看不到 prefetch 请求
Chrome DevTools 默认不显示 prefetch 请求，除非你手动在 Network 面板中：
- 清空所有过滤器，或
- 输入
prefetch并勾选对应类型
更常见的“没看到”，其实是没满足触发条件：
- 页面还没
onload（比如有长任务阻塞主线程） - 用户快速关闭标签页或跳转到其他网站
- 目标资源返回
Cache-Control: no-store或max-age=0 -
href是协议相对路径（如//cdn.example.com/icon.png），被当成非法协议而跳过
图标类资源该用 rel="preload" 还是别的
图标（.ico、.png、.svg）属于当前页关键资源，但绝大多数场景下，根本不需要主动预加载。
原因很直接：
- 浏览器会在解析
<head>时自动发现并加载<link rel="icon">，时机足够早 - 图标体积小（通常 < 4KB），DNS+TCP+TLS 开销远大于文件本身
- 加
preload反而可能引发重复请求：<link rel="icon">和<link rel="preload" href="..." as="image">同时存在时，Chrome 会发两次
唯一需要干预的情况是：你用了非标准路径或动态 icon（比如根据主题切换的 SVG），且能确保它一定在首屏渲染前被用到。此时应写：
<link rel="preload" href="/assets/theme-icon.svg" as="image" fetchpriority="high">
注意：as="image" 而不是 as="icon"（HTML 规范里没有 as="icon"），且不要加 crossorigin——图标不涉及跨域资源共享逻辑。
真正容易被忽略的一点：prefetch 不执行任何代码、不解析 HTML、不设置任何 DOM 属性；它只是把二进制数据塞进 HTTP 缓存。所以别指望它“让图标变快”，它连 <link rel="icon"> 的行为都碰不到。
