prefetch对长流程表单根本不起作用——它仅预存js/css至http缓存，不预渲染、不执行js、不恢复表单状态；用户填到第三步才点“下一步”时，第二步的prefetch甚至未触发，因它依赖onload完成、主线程空闲且页面未卸载，而表单页常被校验逻辑、埋点sdk等阻塞onload。
prefetch 对长流程表单根本不起作用
它不预渲染、不执行 JS、不恢复表单状态，只把 JS/CSS 文件存进 HTTP 缓存。用户填到第三步才点「下一步」，第二步的 <link rel="prefetch"> 甚至还没触发——因为 prefetch 必须等当前页 onload 完成、主线程空闲、页面未卸载，而表单页常被校验逻辑、埋点 SDK、第三方脚本拖慢 onload。
写了但 Network 面板看不到请求的真正原因
不是代码错了，是浏览器压根没执行：
-
Chrome DevTools默认过滤prefetch请求，必须手动勾选 “prefetch” 过滤器才能看见 -
href是相对路径（如./step3.js），在子路由下解析失败，静默忽略 -
as属性缺失或错写（比如as="fetch"），降级为as="document"，部分浏览器直接丢弃 - 目标 URL 跨域（协议/域名/端口任一不同），连 DNS 查询都不会发起
唯一可能生效的场景：预加载最终提交页
如果整个流程最后统一跳转到一个无动态参数、纯静态的提交页（如 /submit），且该页资源由构建工具输出为固定文件名，可以谨慎使用：
-
href必须是绝对或根相对路径，例如/assets/submit.8a2f.js，不能是./submit.js -
as值必须准确：as="script"用于 JS，as="style"用于 CSS - 别用
as="font"或as="document"预取 HTML——前者不触发 CORS 预检，跨域字体大概率失败；后者因含动态 nonce/token，缓存后可能白屏 - 验证是否生效：Network 面板里找
Initiator是prefetch、Priority是Low、状态码是200 (from memory cache)或304
真正影响体验的瓶颈不在资源下载
长流程表单卡顿的核心，是每次跳转带来的完整生命周期开销：
- 组件重新挂载（React/Vue mount）、状态重置
- 接口重复请求（
/api/step3每次都得重发） - 表单字段丢失、滚动位置重置
- 浏览器丢弃
history.state，无法回退时恢复步骤
这些，prefetch 一个都解决不了。最容易被忽略的是：你花时间调 prefetch 的时候，真正的优化点——改成单页 + history.state 管理步骤、用 sessionStorage 持久化输入、提前拉取后续接口——反而一直没动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
