preload写错等于白加还抢带宽：as漏写或错误致优先级降为Low，放<body>或stylesheet后浏览器不识别，重复preload干扰img预解析；prefetch批量声明挤占移动端流量，Safari默认禁用，验证须看Network面板Initiator和Priority列。
preload 写错位置或类型，等于白加还抢带宽
preload 不是“写了就快”，而是“写错就拖慢”。它强制浏览器立刻发起 High 优先级请求，一旦用错场景或参数，就会挤占首屏关键资源的连接数和带宽。
-
as属性漏写或写错（比如字体写成as="style"），浏览器降级为 Low 优先级，和普通 fetch 无异，但依然占用 HTTP/2 流 - 放在
<body>里或<link rel="stylesheet">后面——浏览器根本不识别，请求不会发出，但开发者误以为生效，后续盲目叠加更多 preload - 对
<img src="/hero.jpg">手动加<link rel="preload" href="/hero.jpg" as="image">：现代浏览器已内置 img 预解析，重复声明反而干扰默认行为，且无法复用srcset或sizes
prefetch 大量静态声明，移动端流量直接告急
prefetch 看似“空闲时才下载”，但实际不控制并发、不保证执行、也不反馈失败。批量写几十个到 <head>，用户只访问首页，却强制下载所有路由 chunk，后果比想象中更糟。
- Chrome 对同域名 prefetch 并发数限制极严（通常 ≤2），其余请求被挂起甚至丢弃，但内存仍预留缓存 slot，Android WebView 可能因此触发资源回收
- Safari 默认关闭 prefetch（
network.prefetch-next = false），Firefox 也需手动开启，写了可能完全不触发 - href 用相对路径（如
./js/profile.js）在子路由下解析失败，浏览器静默忽略，但开发者误判为“已预取”，线上出问题才排查
怎么验证 preload/prefetch 真被用了？别信代码写了就行
光看 HTML 里有没有那行 <link> 没意义。必须进 Chrome DevTools → Network 面板，用真实条件交叉验证。
- 筛选器勾选
prefetch或preload—— DevTools 默认过滤掉 prefetch 类型请求 - 查
Initiator列：应显示preload或prefetch，若为parser或空，说明是浏览器自己发现的，你加的标签冗余 - 看
Priority列：preload应为Highest/High，prefetch必须是Low；出现Medium就代表as或crossorigin没配对
真正省带宽的做法：动态 + 条件 + 路径可控
硬编码一堆 link 标签是最容易踩的坑。带宽节省不靠“少写”，而靠“只在确定要的时候才发请求”。
立即学习“前端免费学习笔记（深入）”；
- 路由级 prefetch 改成交互触发：鼠标 hover 导航菜单项时，用
document.createElement('link')动态注入对应 chunk 的<link rel="prefetch" href="/js/product.js" as="script"> - 表单步骤预取：第一步邮箱校验通过后，再加载第二步 JS，避免用户放弃注册却已下完全部资源
- prefetch 前先
<link rel="preconnect" href="https://cdn.example.com" crossorigin>，但不超过 4–6 个，且确保跨域域名真要用到，否则连接闲置也是开销
Cache-Control: public, max-age=31536000，浏览器会直接跳过缓存，下次跳转还是重新拉——等于白跑一趟，还耗了用户流量。 
