link rel="prefetch"对长流程表单基本无效——它仅预存静态资源至HTTP缓存，不预渲染、不执行JS、不恢复状态，无法解决组件挂载、接口请求、表单校验等核心瓶颈。
link rel="prefetch" 对长流程表单没有毫秒级提升——它根本不会触发页面初始化、状态恢复或接口请求，所谓“秒开”是误判。
为什么 prefetch 在多步表单里基本不生效
浏览器只在当前页 onload 完成后才启动 prefetch，而长流程表单页往往卡在 JS 初始化、第三方 SDK 加载、路由解析上，onload 被拖到 2–5 秒后；此时用户早点击了「下一步」，prefetch 根本没机会发出。
- 目标页若含动态参数（如
/form/step3?token=xyz），你无法在 HTML 里写死href；动态插入<link>标签会被浏览器忽略（必须解析时已存在于<head>） - 即使 JS 文件进了缓存，
fetch()还得重发，表单数据不会自动带过去，localStorage或sessionStorage也得自己读写 - Chrome DevTools 默认不显示 prefetch 请求，Network 面板里搜不到 ≠ 没写错，更可能是压根没触发
哪些场景下它唯一可能起作用
仅当满足全部条件时，link rel="prefetch" 才有可测收益：
- 整个流程最终跳转到一个静态提交页（如统一的
/submit），且该页无动态参数、纯展示+按钮 - 路径是绝对或根相对（
/assets/submit.chunk.js），不能是./xxx或带 query 的 URL -
as值准确：JS 用as="script"，CSS 用as="style"，写成as="fetch"或漏掉会降级甚至静默忽略 - 服务端返回
Cache-Control: public, max-age=31536000，资源带 contenthash，不是每次构建都变的临时文件
真正影响表单跳转速度的瓶颈在哪
长流程表单的核心耗时从来不在静态资源加载：
立即学习“前端免费学习笔记（深入）”；
- 组件挂载（React/Vue 实例初始化、hooks 执行）
- 接口响应（
/api/step3这类带用户上下文的请求） - 表单校验逻辑（尤其是依赖远程校验的字段）
- 滚动位置恢复、焦点管理、history.state 丢失
这些环节 prefetch 完全不碰——它只往 HTTP 缓存里塞个 JS 文件，别的不管。
替代方案比瞎加 prefetch 更有效
与其纠结 link rel="prefetch"，不如做这几件确定性高的事：
- 把多页表单改造成单页（SPA），用
URL hash或history.state控制步骤，避免整页跳转 - 对关键接口做预请求（比如用户填完邮箱后，提前
fetch('/api/check-email')） - 用
rel="preload"加载当前页必用资源（如首屏表单组件的 JS chunk） - 用
rel="preconnect"提前连目标 API 域名（href="https://api.example.com"，记得加crossorigin）
prefetch 的本质是“空闲时悄悄拉个文件”，不是魔法开关；在表单场景里，它最容易被忽略的限制，恰恰是它最不可绕过的硬门槛：同源、静态路径、onload 后触发、无 JS 执行能力。
