Prefetch对在线预览页跳转几乎没用，因其要求资源同源、路径静态、强缓存且用户行为可预测，而预览页URL动态、内容不可控、缓存策略短效、停留时间短，导致prefetch请求常被忽略或未触发。
Prefetch 对在线预览页跳转几乎没用，除非你明确知道用户下一步点哪一页，且该页资源是静态、同源、强缓存的 JS/CSS。
为什么在线预览页不适合用 prefetch
在线预览场景（比如文档/代码/设计稿预览）通常具备这几个特征：页面 URL 动态生成（/preview?id=abc123）、内容不可预测、用户行为高度分散（可能翻页、跳章节、切版本、导出 PDF），而 prefetch 的核心限制直接撞上这些：
- 它只对同源、绝对路径有效的资源生效；动态拼接的
href（如/preview?id=def456）无法提前写死，也大概率被浏览器忽略 - 它依赖服务端返回
Cache-Control: public, max-age=31536000，但预览页资源常带 hash 或临时 token，缓存策略往往设为no-store或短时效 - 用户在预览页停留时间短、操作快，
onload都没触发就已跳走，prefetch 请求根本不会发出 - Chrome DevTools 里搜
prefetch看不到请求，不等于没写错——更可能是浏览器压根没执行
什么情况下可以谨慎试一试
仅当满足全部以下条件时，prefetch 才可能带来可测收益：
- 预览系统有固定“下一页”逻辑，比如教程类站点的
/lesson/1→/lesson/2，且路径是静态的 - 目标页的 JS/CSS 是构建产物（如
/js/lesson2.8a3f.js），带 contenthash，服务端配了长期强缓存 - 当前页 DOM 加载完成耗时稳定（
onload可靠触发），且用户平均停留 > 2s - 你愿意在
<head>里硬编码几条<link rel="prefetch" href="/js/lesson2.8a3f.js">，并接受部分浏览器（如 Safari）完全无视
示例写法：<link rel="prefetch" href="/js/next-preview.bundle.js"> —— 放在 <head> 任意位置即可，不用等 DOM，但必须是合法相对或绝对路径。
立即学习“前端免费学习笔记（深入）”；
比 prefetch 更靠谱的替代方案
在线预览页的跳转卡顿，根源通常不在“资源没提前下”，而在“资源下了但没及时用”或“关键路径太长”。优先检查这些：
- 首屏是否用了
preload加载 LCP 图片、字体、关键 CSS？prefetch解决不了首屏慢，preload才管这个 - 预览容器是否用
loading="lazy"或 IntersectionObserver 做了按需渲染？避免一次性加载全部分页内容 - 是否把预览逻辑打包进单个 chunk，而不是每个预览页都拉一遍完整框架？减少重复 JS 解析开销
- CDN 是否开启 Brotli 压缩 + HTTP/2 多路复用？实测比瞎加 prefetch 对 TTFB 影响更大
真正影响预览页跳转体验的，往往是服务端响应速度、JS 执行耗时、以及是否意外触发了同步 layout。prefetch 是个窄口径优化，写错一行路径或缓存头，就等于白加。
