fetchpriority在标签上仅对rel="stylesheet"有效，且需chromium 112+/safari 17.2+支持；rel="preload"等其他类型均不支持，因preload已锁定最高优先级、prefetch无调度上下文、icon等根本不识别该属性。
fetchpriority 属性在 <link> 标签上基本无效，除非是 rel="stylesheet" 且浏览器版本足够新（Chromium 112+ 或 Safari 17.2+），其他类型如 rel="preload"、rel="prefetch"、rel="icon" 均不支持。
哪些 <link> 类型真正支持 fetchpriority？
目前仅两类有实际效果：
-
<link rel="stylesheet" href="critical.css" fetchpriority="high">：Chrome/Edge 112+ 和 Safari 17.2+ 支持，Firefox 完全忽略 -
<link rel="stylesheet" href="theme.css" fetchpriority="low">：语义上合理（非阻塞主题样式），但实测调度降级效果弱于<img>，多数仍显示为Medium
以下写法全是徒劳：
-
<link rel="preload" href="font.woff2" as="font" fetchpriority="high">——preload本身已锁定Highest优先级，fetchpriority被静默丢弃 -
<link rel="prefetch" href="next-page.html" fetchpriority="low">—— prefetch 不走主加载队列，该属性无调度上下文 -
<link rel="icon" href="favicon.ico" fetchpriority="low">—— 浏览器根本不识别此组合，Network 面板中 Priority 列无变化
为什么 <link rel="stylesheet"> 的 fetchpriority 效果不稳定？
它受三重逻辑压制：
- CSS 加载天然阻塞渲染，浏览器默认就给
High或Highest，fetchpriority="high"往往只是“确认”而非提升 - 若 CSS 文件已被缓存，Network 面板 Priority 显示为
Medium—— 不是失效，而是调度器认为无需抢占带宽 - 当页面存在多个
<link rel="stylesheet">，浏览器会按 HTML 出现顺序 + 渲染依赖推导优先级，fetchpriority无法逆转这个顺序
典型现象：fetchpriority="low" 设在非关键 CSS 上，Chrome DevTools 中 Priority 仍为 Medium，因为“低优先级样式”本身就不该抢资源，调度器直接按默认策略处理。
和 <img> 相比，<link> 的 fetchpriority 更容易踩哪些坑？
关键差异在于解析时机与资源绑定方式：
-
<img src>的fetchpriority在 HTML 解析时立即触发预加载扫描；而<link rel="stylesheet">的优先级提示可能被 CSS 解析器延迟读取，尤其当href是 JS 动态拼接时（哪怕写在 HTML 里，若含data-占位符且被 JS 替换，也视为无效） -
<link>不支持loading属性，所以不存在lazy冲突问题，但这也意味着你无法用组合策略（如loading="lazy" fetchpriority="low"）做双重保险 - 跨域 CSS 若未返回
Access-Control-Allow-Origin，CORS 预检失败会导致整个请求降级，fetchpriority提示信号随之丢失
最常被忽略的一点：如果你在 里写了 <link rel="stylesheet" fetchpriority="high">，但该 CSS 实际通过 @import 引入另一份 CSS，那么子资源完全不受父标签的 fetchpriority 影响——提示信号不会穿透 import 链。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
