大概率是缓存没命中——prefetch确实发起了请求并进入HTTP缓存，但下一页未复用，根本原因是服务端响应头未配置可复用缓存策略（如Cache-Control: public, max-age=31536000），导致下次跳转仍重拉资源。
prefetch 资源没被下一页用上，是缓存没命中还是根本没加载？
大概率是缓存没命中——prefetch确实发起了请求、也进了 HTTP 缓存，但下一页加载时没复用，本质是服务端响应头没配对。
- 必须确保 prefetch 资源返回的
Cache-Control是可复用的，比如public, max-age=31536000；no-cache或private会导致下次跳转仍重拉 - 同一资源在 A 页面
prefetch，B 页面用<script src="/js/next.js"></script>加载，只有 URL 完全一致（含查询参数）才可能命中；/js/next.js?v=1和/js/next.js?v=2视为两个资源 - 浏览器不会校验 ETag 或 Last-Modified 去做协商缓存，只认 Cache-Control + URL；若服务端动态生成 JS 且没设强缓存，prefetch 白忙一场
为什么 Network 面板里看不到 prefetch 请求？
不是代码无效，而是你没看到它——Chrome 默认过滤掉 prefetch 类型请求，且它只在特定条件下才真正发起。
- 必须手动在 DevTools Network 面板勾选
prefetch过滤器，或清空所有过滤条件；否则它藏在“Other”里也不显示 - 页面还没触发
window.onload（比如有长任务卡住主线程、某张图片一直 loading 中），prefetch 就不会启动 - 用户快速关闭标签页或跳转离开，浏览器会直接取消请求，Network 显示
cancelled，不是失败而是主动放弃 - href 写成相对路径如
./js/next.js，在子目录页会被解析成错误地址，静默失败；必须用根相对路径/js/next.js或绝对路径
as 属性写错或不写，对 prefetch 命中率有多大影响？
影响不小：不写 as 或写错，浏览器无法预判资源类型，可能降级处理甚至忽略，导致缓存策略失效或解析延迟。
-
as="script"和as="document"对应的缓存行为不同：前者进 script 缓存区，后者走 HTML 缓存逻辑；混用可能让下一页的<script>标签拿不到预期缓存 - 字体、图片类资源慎用
prefetch：字体需crossorigin，但prefetch不触发 CORS 预检，容易静默失败；图片没设as="image"，浏览器按 MIME 推断，若服务端返回text/plain就直接丢弃 - 常见错误：
as="fetch"（非法值）、as="font"（prefetch 不支持 font 类型）、as="style"用于 CSS 文件但没配crossorigin（同源也建议加）
多个 prefetch 并发时，浏览器怎么分配带宽？
它不分配——prefetch 没有并发控制，全靠浏览器空闲判断；但现实是：它常被系统级限制压到只剩 1–2 个连接，尤其在低端设备或省流模式下。
立即学习“前端免费学习笔记（深入）”；
- Chrome 对 prefetch 限流严格：默认最多同时发起 2–3 个请求，且优先级标为
Low，一旦 CPU 或网络负载升高就暂停 - 别在首页一口气写 5 个
prefetch，尤其是都指向大 JS 或 HTML；不如聚焦 1–2 个最高概率路径（如“下一步”按钮目标页） - 配合
<link rel="preconnect" href="https://cdn.example.com" crossorigin>提前建连，能减少 DNS/TCP/TLS 开销，让 prefetch 真正发起时更快完成 - 移动端尤其要注意：Android Chrome 在后台标签页中会暂停所有 prefetch，iOS Safari 对非脚本类资源（.css/.jpg）基本不执行 prefetch
Initiator 列是否为 prefetch，以及跳转后资源状态码是不是 200 (from memory cache) 或 304。 
