link rel="prefetch" 对长流程表单基本无效——它仅预存静态资源至HTTP缓存，不预渲染、不执行JS、不恢复状态；无法解决组件挂载、接口请求、表单校验等核心瓶颈。
link rel="prefetch" 对长流程表单没用——它不预渲染、不执行 JS、不初始化状态，只存静态资源到 HTTP 缓存。用户填到第三步才跳转？那第二步的「下一步」按钮点击前，根本不会触发 prefetch；就算触发了，跳过去依然要重新 mount 组件、拉接口、校验字段、恢复滚动位置。
为什么长流程表单里写 link rel="prefetch" 基本白忙
长流程表单（比如 5 步注册/报销/入驻）的核心瓶颈不在资源下载，而在：页面初始化耗时（React/Vue 组件挂载 + 状态还原）、接口响应（/api/step3）、表单校验逻辑、以及浏览器对跨页面 history.state 的丢弃。而 link rel="prefetch" 只解决其中最不痛的一环：JS/CSS 文件的磁盘读取延迟。
- 它必须等页面
onload后才启动，而长流程表单页往往有大量初始化 JS、埋点、第三方 SDK，onload被拖到几秒后 - 目标页若依赖动态路由参数（如
/form/step4?token=abc），你没法在 HTML 里写死href；动态插入link标签又大概率被浏览器忽略（不满足“解析时已存在 DOM”硬条件） - 即使 JS 文件进了缓存，
fetch()还是得重发，表单数据不会自动带过去，localStorage或sessionStorage也得你自己读写 - Chrome DevTools 默认不显示 prefetch 请求，你以为写了就生效，其实 Network 面板里压根没发起——连失败都看不到
prefetch 在表单场景唯一靠谱的用法：预加载「最终提交页」的静态资源
如果整个流程最后是统一的提交页（比如所有步骤都 POST 到 /submit，且该页无动态参数、纯展示+按钮），那可以提前预加载它的 JS 和 CSS：
<link rel="prefetch" href="/assets/submit.chunk.js" as="script"> <link rel="prefetch" href="/assets/submit.css" as="style">
但要注意：
立即学习“前端免费学习笔记（深入）”；
- 路径必须是绝对或根相对（
/assets/xxx），不能是./xxx，否则子路由下解析失败 -
as值必须准确：JS 用as="script"，CSS 用as="style"，写成as="fetch"或漏掉会降级为as="document"，甚至静默忽略 - 别 prefetch 字体（
as="font"）——prefetch 不触发 CORS 预检，跨域字体大概率失败 - 验证是否生效：Network 面板勾选 “prefetch”，看 Initiator 是
prefetch，Priority 是Low，跳转后资源状态码是200 (from memory cache)或304
真正提升长流程表单体验的替代方案
与其折腾 prefetch，不如做这几件事：
- 把多页表单改造成单页（SPA）+ URL hash/state 控制步骤，避免整页跳转；用
keep-alive或React.memo缓存已填步骤组件 - 在用户停留某一步超过 1.5s 时，用
import()动态导入下一步的代码块（比prefetch更可控、可 await、可加 loading） - 用
sessionStorage持久化每一步的表单值，用户刷新或误关页也能恢复；配合beforeunload提示保存 - 对关键接口（如
/api/step3）用rel="preconnect"提前建连，省掉 300ms TLS 握手（尤其跨域 API）
prefetch 的价值在于「用户大概率点、资源确定、路径静态、无状态依赖」的场景——比如商品列表页预取详情页。长流程表单恰恰相反：路径动态、状态强耦合、用户行为不确定。强行套用，只会让你花半天调 Network 面板，最后发现缓存里啥都没多出来。
