会，prefetch在2g或弱网下几秒内消耗1–2mb流量，因它无视网络状况、强制加载完整页面资源且无法监控中断。
会，而且浪费得又快又隐蔽——2G 或弱网下几秒就能吃掉 1–2 MB，用户根本没点进去，浏览器还在后台硬下。
prefetch 在慢网下为什么特别耗流量
它不看网络状况，只看“浏览器空闲”。只要页面 onload 完成、主线程没任务、用户没切页，prefetch 就立刻以 Low 优先级发起请求。但 Low ≠ 小流量：as="document" 时，它会把目标 HTML 里所有 script、link、img 标签引用的资源一并拉下来，实际下载量远超 HTML 本身。
- 实测 iOS Safari + 2G 模拟下，一个
as="document"的 prefetch 请求，3 秒内下载达 1.4 MB（含连带 JS/CSS/图片） - Chrome 在“节省流量”模式下默认跳过 prefetch，但 Safari 和多数安卓 WebView 没这个开关，照常执行
- DevTools Network 面板默认不显示 prefetch 请求，必须手动勾选 “prefetch” 过滤器才能看见——意味着你根本不知道它在偷偷跑
as="document" 是流量黑洞的主因
很多人以为 prefetch 只下 HTML，其实 as="document" 触发的是完整页面预渲染级加载：浏览器会解析返回的 HTML，顺手 fetch 所有 src 和 href 资源，且不区分是否在视口、是否会被执行。
- 错写成
as="html"或漏写as，浏览器可能降级为as="document"，反而更危险 - 服务端若未对 prefetch 请求做特殊响应（比如返回精简版 HTML），就会原样吐出完整页面资源树
- 字体、图片、第三方脚本全被拉一遍，而这些资源在用户真正访问前，99% 不会被用到
移动端没法靠“用户行为”止损
桌面端还能靠 hover 触发动态 prefetch，但移动端没有 hover，常见 fallback 方式（如 scroll、touchstart）容易误触发，且无法判断用户是否真要跳转。
-
IntersectionObserver监听导航链接进入视口？移动端小屏幕+手势滑动，链接可能刚进视口就又被划走，但 prefetch 已发出 - 路由级预取（如 React Router 的
useNavigate前预取）依赖 JS 控制，但 prefetch 必须静态写在里，动态插入基本无效 - 用户点了返回键或切到其他 App，prefetch 请求仍继续下载——浏览器不会中止，直到完成或系统强制终止
真正麻烦的不是“要不要用”，而是“用了之后根本没法监控和中断”。哪怕你写了 Cache-Control: immutable，它也不发请求；但一旦发了，就一路跑到底，连 DevTools 都不告诉你下了多少字节。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
