<link rel="prefetch">不是“加了就快”，而是“在用户大概率会点进去时，悄悄把资源塞进HTTP缓存里”；它不优化首屏、不执行脚本、不发API请求，误用会浪费流量、污染缓存，且Safari旧版基本无效。
会，而且是静默、不可控、不可监控地耗光流量。
prefetch 在 2G/3G/弱蜂窝网下几秒吃掉 1–2 MB
浏览器一旦发起 prefetch 请求，就不会因为用户切页、关闭标签或刷新而中止——它会在后台持续下载完整资源，哪怕当前页面 DOM 已销毁。尤其当 as="document" 时，还会连带加载该 HTML 中引用的 JS/CSS/图片，实际消耗远超预期。
- 移动端在 2G 或弱网下，一个
/product/123.html预取可能几秒内就耗掉 1.2 MB 流量，而用户根本没点进去 - Chrome/Safari 都不提供“已预取多少字节”的监控入口，
DevTools Network面板里也看不到缓存状态（它走 HTTP 缓存，不是内存缓存） - 默认过滤器会隐藏
prefetch请求，必须手动勾选才能看到，排查困难
为什么你关了页面它还在下
prefetch 不是“页面级”请求，而是浏览器级后台任务。它的生命周期独立于页面：只要请求已发出，就继续下载直到完成或网络中断。
- 用户滑两屏就关掉页面？请求仍在后台跑
- 跳转到新路由？旧页面的
prefetch不会 cancel，除非网络断开 - 没有 API 可监听进度或失败，也无法做 fallback（比如失败后改用
import()）
静态写死 prefetch 是最危险的操作
硬编码到模板里的 <link rel="prefetch"> 会无差别触发，等于强制所有用户下载一个可能永远用不到的资源。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 电商首页模板里写了 5 个商品详情页
prefetch？90% 用户只看前两屏就离开，但流量已扣完 - Safari 直到 iOS 16.4 才稳定支持
as="document"，旧版 WebView 完全无视——写了白写，还占 HTML 体积 - 跨域
prefetch在 Firefox/Safari 中基本被无视，Chrome 虽支持但需服务端配合 CORS，实际很少生效
真正可控的做法只有动态 + 条件判断
把预取时机绑定到用户真实意图上，而不是页面加载完成那一刻。
- 监听商品卡片进入视口（
IntersectionObserver），延迟 200ms 后调用document.createElement('link')注入prefetch - 只预取构建后确定路径的资源，比如 Vite 输出的
/assets/detail.8a2b.js，不预取/product/123这类路由地址（服务端可能返回 404 或重定向） - 避免对 API 接口（如
/api/cart/add）写prefetch——它不发fetch请求，也不解析响应体，只存二进制 blob
复杂点在于：prefetch 本身不提供 JS 可读接口，无法监听是否成功或失败；预取的 HTML 必须是静态可缓存的，不能含动态 nonce/token；且它根本不参与带宽调度，没有并发控制、优先级抢占或进度监听能力。
