link rel="prefetch"对多步表单基本无效——它仅预存JS/CSS至HTTP缓存，不预渲染、不执行JS、不恢复状态，无法解决组件挂载、接口请求、表单校验等核心瓶颈。
link rel="prefetch" 对多步表单根本不起作用
它只存 JS/CSS 到 HTTP 缓存，不执行任何逻辑——表单跳转后组件要重新 mount、接口得重发、校验逻辑照跑、滚动位置不会恢复。用户填到第三步才点「下一步」？那第二步的按钮点击前，prefetch 根本不会触发；就算触发了，资源进了缓存，页面照样白屏几秒等初始化。
写了但 Network 面板看不到请求的常见原因
不是代码写错了，而是浏览器压根没执行它：
- Chrome DevTools 默认过滤
prefetch请求，必须手动勾选 “prefetch” 过滤器才能看到 - 页面还没触发
onload（比如有长任务卡主线程），prefetch就被挂起 -
href是相对路径（如./step4.js），在子路由下解析失败，静默忽略 -
as属性缺失或错写（比如as="fetch"），降级为as="document"，甚至被浏览器丢弃 - 目标 URL 跨域（协议/域名/端口任一不同），连 DNS 查询都不会发起
唯一可能有点用的场景：预加载最终提交页
如果整个流程最后统一跳转到一个无参数、纯静态的提交页（比如所有步骤都 POST 到 /submit），可以谨慎预加载它的资源：
- 路径必须是绝对或根相对，例如
/assets/submit.chunk.js，不能是./submit.js -
as值必须准确：as="script"用于 JS，as="style"用于 CSS - 别碰字体：
prefetch不触发 CORS 预检，跨域字体大概率加载失败 - 验证是否生效：Network 面板里找 Initiator 是
prefetch、Priority 是Low、状态码是200 (from memory cache)或304
真正该做的不是写 prefetch，而是砍掉整页跳转
多步表单的性能瓶颈从来不在资源下载，而在每次跳转带来的完整生命周期开销。最直接有效的优化是：
立即学习“前端免费学习笔记（深入）”；
- 把五步表单改成单页应用（SPA），用
URL hash或history.state控制步骤，避免整页 reload - 提前拉取后续步骤所需接口数据（比如用户点「下一步」前，就用
fetch()预取/api/step3） - 用
sessionStorage或React context持久化已填字段，跳步时不丢失输入 - 对非首屏步骤的组件做懒加载：
React.lazy+Suspense，或动态import()
写 prefetch 是在给错误的问题找补丁，而真正的瓶颈藏在路由设计和状态管理里——这点最容易被忽略，也最难回退。
