prefetch在多步表单中常“没反应”，因其仅在onload完成、主线程空闲、网络可用且页面未卸载时才触发；而表单常因JS校验、动画等阻塞onload，或用户快速跳转导致请求被取消。
prefetch 为什么在多步表单里经常“没反应”
它根本不是一写就发请求的机制。浏览器只在当前页 onload 完成、主线程空闲、网络带宽低优先级可用、且页面还没被卸载时，才可能触发 prefetch。多步表单常有 JS 校验、动画、异步提交等阻塞 onload 的操作，导致 prefetch 始终不启动。用户填完第一步立刻点“下一步”，页面跳转了，prefetch 还没来得及发请求——这不算 bug，是设计如此。
常见表现包括：Network 面板看不到请求（默认过滤器屏蔽了 prefetch）、目标资源返回 404 或 net::ERR_FAILED（路径写错或服务端未部署）、Safari 直接静默忽略（尤其 as="document" 在 iOS 16.4 之前基本无效）。
怎么写才能让第二步资源真正进缓存
必须满足三个硬性条件，缺一不可：
- <link> 必须静态写在首屏 HTML 的 <head> 中，动态插入（如 document.head.appendChild()）多数情况下无效
- href 必须是绝对路径或根相对路径（如 /form/step2.chunk.js），不能用 ./step2.js 或 step2.html（嵌套路由下解析易错）
- as 属性必须准确：JS 文件用 as="script"，CSS 用 as="style"，HTML 页面用 as="document"（但强烈建议避开预取 HTML，详见下一条）
示例正确写法：<link rel="prefetch" href="/form/step2.7f8a.js" as="script">
注意：如果构建产物中 step2 是一个独立 chunk，且已分离出对应 CSS，则应再加一行：<link rel="prefetch" href="/form/step2.e2d9.css" as="style">
为什么别用 prefetch 预取 /form/step2.html 这类页面地址as="document" 表面看合理，实际风险极高：
- 服务端返回的 HTML 若含动态 nonce、CSRF token、时间戳等不可缓存内容，prefetch 存入缓存后，下次导航加载会执行失效代码，直接白屏或报错
- 浏览器 prefetch HTML 时，会顺带拉取其中所有 <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 更简单可靠的替代方案
如果你的第二步是个代码分割模块（比如 React 的 lazy(() => import('./Step2'))），直接调用 import() 就行：
- 浏览器自动按需 prefetch，优先级略高于 rel="prefetch"
- 不需要操心 as、crossorigin、路径拼写，现代浏览器全部支持
- 可配合行为触发（如按钮 hover 后 200ms）避免误触：button.addEventListener('mouseenter', () => setTimeout(() => import('./Step2'), 200))
真正容易被忽略的是：prefetch 不是“提前执行”，它只是提前下载。哪怕资源进了缓存，如果第二步页面的 JS 执行逻辑依赖服务端实时数据、或用了未被 prefetch 的子资源（比如某张图没声明 as="image"），体验也不会变快。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
