prefetch在多步表单中常“没反应”是因为它必须等onload完成、主线程空闲且页面未卸载才触发，而JS校验、动画、快速跳转等会阻塞或取消其执行；生效需同时满足：静态写入head、绝对/根相对路径、as属性准确。
为什么多步表单里 prefetch 总是“没反应”
不是代码写错了，而是浏览器根本没触发它。多步表单的常见操作——JS 校验、表单动画、异步提交、动态渲染——都会延迟 onload 事件，而 prefetch 必须等 onload 完成且主线程空闲才可能启动。用户填完第一步立刻点“下一步”，页面跳转了，prefetch 还没来得及发请求，这是设计行为，不是 bug。
常见表现包括：Network 面板看不到请求（默认过滤器屏蔽 prefetch）、目标资源返回 404 或 net::ERR_FAILED（路径写错或服务端未部署）、Safari 对 as="document" 静默忽略（iOS 16.4 之前基本不发起）。
prefetch 在多步表单中真正生效的三个硬性条件
缺一不可，否则大概率白写：
-
<link rel="prefetch">必须静态写在首屏 HTML 的<head>中，动态插入（如document.head.appendChild()）多数情况下无效 -
href必须是绝对路径或根相对路径（如/form/step2.7f8a.js），不能用./step2.js或step2.html（嵌套路由下解析易错） -
as属性必须准确：JS 文件用as="script"，CSS 用as="style"，HTML 页面用as="document"（但强烈建议避开预取 HTML）
为什么别用 prefetch 预取 /form/step2.html 这类路由地址
表面合理，实际风险极高：
立即学习“前端免费学习笔记（深入）”；
- 服务端返回的 HTML 若含动态
nonce、CSRF token、时间戳等不可缓存内容，prefetch存入缓存后，下次导航加载会执行失效代码，直接白屏或报错 - 浏览器预取
as="document"时，会顺带拉取其中所有<link rel="stylesheet">和<script>，但这些子资源未必被声明为prefetch，导致缓存键不一致，复用失败 - Safari 对
as="document"支持极差，iOS 16.4 之前几乎不发起请求；Chrome 虽支持，但若响应头缺失Cache-Control: public, max-age=31536000，后续跳转仍不会复用
更稳妥的做法是只 prefetch 构建产物中确定存在的静态资源文件（如 Webpack/Vite 输出的 step2.xxx.js 和 step2.xxx.css），而不是路由路径。
验证 prefetch 是否真起作用的关键动作
不能只看 Network 面板有没有请求，得确认它是否进了缓存、并在后续导航中被复用：
- 打开 Chrome DevTools → Network 面板 → 取消所有过滤器，或手动输入
prefetch过滤 → 刷新页面观察是否有 low-priority 请求 - 点开该请求，检查 Response Headers 中是否有
Cache-Control: public, max-age=31536000，且Content-Type匹配（如 JS 应为application/javascript） - 跳转到第二步时，观察 Network 面板对应资源是否显示
from memory cache或from disk cache，而非新请求 - 注意：若目标资源返回
Cache-Control: no-store或max-age=0，浏览器连请求都不会发
最常被忽略的是服务端缓存头和路径解析逻辑——写对了标签，但路径错一位或缓存策略没配，整个预取就失效了。
