prefetch资源缓存在浏览器网络栈临时托管区，非独立缓存类型；其是否进入disk/memory cache取决于服务端响应头（如cache-control），而非prefetch标签本身。
prefetch 资源到底缓存在哪儿？
浏览器对 <link rel="prefetch"> 的缓存行为没有强制标准，它不走常规的 HTTP 缓存（Cache-Control、ETag 等）主流程，而是由浏览器内部网络栈（net-stack）临时托管。Chrome 当前（2026 年）仍基本遵循 Addy Osmani 早年指出的规则：prefetch 请求会在网络层缓存至少 5 分钟，但前提是资源本身允许被缓存（即响应头未设 no-store 或 no-cache）。若服务端返回 Cache-Control: no-store，即使 prefetch 触发了，也不会进入可复用缓存，下次访问仍会重新请求。
为什么 Network 面板看不到 “prefetch cache”？
因为这不是一个独立缓存类型，它不显示在 Memory Cache 或 Disk Cache 标签页里。验证是否生效，应关注两点：
- 在 Chrome DevTools 的
Network面板中筛选JS或Document，找状态为(prefetch cache)的条目（仅当该资源被后续导航真正使用时才出现） - 更可靠的判断方式：打开
Network→ 点击某个 prefetch 条目 → 查看Headers里的Request Headers是否含purpose: prefetch - 若资源被复用，Waterfall 中的
Waiting (TTFB)会极短（接近 0ms），且Size显示为from disk cache或from memory cache（取决于实际存储位置）
如何让 prefetch 资源真正进磁盘缓存？
关键不在 <link> 标签本身，而在服务端响应头配置。必须确保目标资源返回合理的缓存策略：
- 静态 JS/CSS/HTML 文件建议设：
Cache-Control: public, max-age=31536000, immutable - 带版本哈希的资源（如
app.a1b2c3.js）天然适合 long-term caching - 避免对 prefetch 目标资源返回
no-cache、no-store或max-age=0 - 注意：即使加了
as="script"，若响应头禁止缓存，prefetch 也白做
prefetch 和 preload 在缓存行为上根本不同
preload 是为当前页面服务，加载后至少进内存缓存，且优先级高、立即触发；prefetch 是为未来页面准备，优先级最低、延迟执行，且缓存与否高度依赖服务端响应头和浏览器空闲状态。滥用 prefetch（比如对首页首屏资源也写 prefetch）不仅不会加速，反而可能挤占带宽、延迟关键资源下载。移动端尤其明显——4G 网络下 prefetch 多余请求容易拖慢首屏渲染。
