rel="prefetch"预加载CSS必须写as="style"，写as="css"、as="fetch"或漏掉as会导致请求静默降级为普通GET，不进HTTP缓存、不触发低优预取，Network面板无请求且零报错；该标签须静态写入head，动态插入无效，且对白屏时间无改善。
rel="prefetch"预加载CSS必须写as="style"
浏览器只认as="style"这个值，写成as="css"、as="fetch"或漏掉as，请求会静默降级为普通GET，不进HTTP缓存，也不触发低优先级预取逻辑。实际效果就是白写。
常见错误现象包括：Network面板看不到请求、资源路径确认无误但始终不下载、控制台零报错。
-
as="style"是强制要求，不是可选项 - 目标CSS文件必须返回
Content-Type: text/css，用curl -I检查响应头 - 若CSS里引用了字体或图片，这些子资源不会被连带预取——
prefetch只管当前URL，不递归解析内容
静态写入HTML head才可靠，动态插入基本无效
在React/Vue等SPA中，路由切换后用JS动态创建<link rel="prefetch" href="/detail.css" as="style">并append到head，Chrome 115+可能偶发生效，Safari完全无视。浏览器只在初始HTML解析阶段或document.readyState === 'interactive'时处理prefetch，之后插入的标签被忽略。
真正能落地的做法只有两种：
立即学习“前端免费学习笔记（深入）”；
- 服务端渲染（SSR）时，根据当前路由，在HTML模板中静态注入对应下一路由所需的
<link rel="prefetch" href="..." as="style"> - 客户端确实需要按交互触发（比如鼠标移入商品卡片），改用
fetch()+cache.put()手动预加载并存入Cache API，兼容性更好且可控
prefetch CSS对白屏时间几乎没帮助
它只把CSS文件塞进HTTP缓存，不解析、不执行、不触发样式计算。用户点击跳转后，新路由组件仍要走完整生命周期：JS执行、DOM挂载、CSSOM构建、重排重绘。即使CSS已缓存，白屏时间也不会缩短。
真正卡顿点从来不在“下载”，而在初始化和渲染流程本身。
- 如果目标CSS是懒加载路由的样式，它本就不该靠
prefetch——应由路由组件加载时通过import('./Detail.module.css')触发，配合modulepreload更合理 - 不要给首屏CSS用
prefetch，那是preload或modulepreload的职责 - 跨域CSS（哪怕只是协议不同）会被浏览器静默忽略，连DNS查询都不会发起
流量和缓存风险必须提前评估
prefetch一旦发起，就不会因用户切页、关闭标签或刷新而中止。尤其当CSS文件较大（比如含大量字体或雪碧图），几秒内就可能消耗1–2MB流量，而用户根本没访问下一页。
更麻烦的是：DevTools Network面板默认不显示prefetch请求，必须手动勾选过滤器；且它走HTTP缓存，没有“已缓存多少字节”的监控入口。
- 移动端弱网环境下慎用，尤其是2G/3G用户
- 若CSS含动态token（如
?t=1678901234），每次生成路径不同，缓存无法复用，纯属浪费 - 同一资源同时写了
preload和prefetch，Chrome会发两次请求——一次高优、一次低优，带宽和缓存都浪费
prefetch加载的静态文件根本不会被引用。 
