prefetch资源不单独存于内存，其是否进入memory cache及留存时长完全由服务端cache-control响应头决定；chrome网络栈仅临时托管响应体最多5分钟，且仅当响应允许缓存时生效。
prefetch资源在内存中到底能留多久
它不单独“存”在内存里，也没有固定时长。所谓“内存中存留”，其实是 HTTP 缓存（memory cache）的一部分，而是否进 memory cache、留多久，完全由服务端响应头决定，link rel="prefetch" 标签本身不控制这个。
Chrome 当前（2026 年）对 prefetch 的实际处理是：网络栈会临时托管该请求的响应体最多 5 分钟，但仅当资源本身允许缓存时才生效。如果服务端返回 Cache-Control: no-store 或 max-age=0，哪怕 prefetch 成功下载了，也不会进入 memory cache 或 disk cache，下次访问照样重发请求。
- 真正起作用的是响应头里的
Cache-Control，不是rel="prefetch"的存在与否 -
immutable能让浏览器跳过 revalidation，配合max-age=31536000才算稳住 memory/disk cache - 即使进了 memory cache，一旦内存压力大，浏览器可能随时丢弃——这不是 prefetch 特有行为，所有 memory cache 都一样
- Network 面板里看到
from memory cache，说明复用成功；但看不到不代表没缓存，可能是被静默淘汰了
为什么 DevTools 里找不到 prefetch 对应的 memory cache 条目
因为 prefetch 不创建独立缓存条目。它走的是标准 HTTP 缓存路径，只是触发时机和优先级不同。你在 Application → Cache Storage 或 Memory Cache 标签页里搜不到它，很正常。
验证方式只有两个可靠入口：
- Network 面板过滤
prefetch，看是否有 low-priority 请求发出；再点开该请求，检查Response Headers是否含有效的Cache-Control - 后续导航真正加载同一资源时，观察 Waterfall 中的
Waiting (TTFB)是否趋近 0ms，且Size显示为from memory cache或from disk cache
as 属性缺失或错配会导致 prefetch “进不了内存”
as 不只是语义提示，它影响浏览器对资源类型的预判和缓存策略。比如写成 as="fetch" 或漏掉 as，浏览器会降级为 as="document"，进而可能忽略缓存头、拒绝存入 memory cache。
- 静态 JS 文件必须用
as="script"，CSS 用as="style"，字体用as="font" -
as="document"风险高：它会尝试解析 HTML，若服务端返回带 nonce/token 的动态 HTML，缓存可能失效 - 构建产物中带哈希的资源（如
app.a1b2c3.js）最适配as="script"+Cache-Control: public, max-age=31536000, immutable
动态插入的 prefetch link 基本无效
浏览器只在 HTML 解析阶段识别 link rel="prefetch"。用 document.createElement('link') 动态加进去，绝大多数情况下不会触发 prefetch 行为——即使 DOM 已就绪，也跨过了关键时机。
- 必须在
中静态声明，确保 HTML parser 阶段就能看到 - SPA 中想按需 prefetch，正确做法是监听用户交互（如 hover、scroll），延迟 200ms 后调用
fetch()+cache.put()存入 Cache API，而不是拼link标签 - Webpack 的
prefetch: true是在构建时静态注入，所以有效；手写 JS 动态 append 不等价
真正难控的不是“怎么写”，而是服务端响应头是否可信、是否稳定、是否被 CDN 或反向代理篡改。哪怕标签写得再标准，只要中间某层返回了 no-cache，prefetch 就等于没做。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
