fetchpriority在标签上仅对rel="stylesheet"有效，且需chromium 112+/safari 17.2+支持；其他rel值如preload、prefetch、icon均不支持，因preload已锁定最高优先级、prefetch无调度上下文、icon根本不识别该属性。
fetchpriority 在 <link> 标签上基本无效，除非是 rel="stylesheet" 且运行在 Chromium 112+ 或 Safari 17.2+ 中；其他类型如 rel="preload"、rel="prefetch"、rel="icon" 均不支持该属性。
哪些 <link> 类型真能用 fetchpriority？
目前只有 rel="stylesheet" 有实际调度效果，且仅限特定浏览器版本：
-
<link rel="stylesheet" href="critical.css" fetchpriority="high">：Chrome/Edge 112+ 和 Safari 17.2+ 会将其优先级提示纳入调度，但 Firefox 完全忽略 -
<link rel="stylesheet" href="theme.css" fetchpriority="low">：语义合理（非阻塞主题样式），但实测降级效果弱于<img>，Network 面板中常仍显示为Medium - 所有其他
rel值均不支持：preload已锁定Highest，prefetch不走主加载队列，icon根本不识别该属性
fetchpriority="high" 在 <link rel="stylesheet"> 上为什么经常没变化？
它受三重逻辑压制，不是“设了就升”：
- CSS 加载天然阻塞渲染，浏览器默认就给
High或Highest，fetchpriority="high"往往只是“确认”，而非提升 - 若 CSS 文件已被缓存，Network 面板中 Priority 显示为
Medium——这不是失效，而是调度器认为无需抢占带宽 - 多个
<link rel="stylesheet">并存时，浏览器按 HTML 出现顺序 + 渲染依赖推导优先级，fetchpriority无法逆转这个顺序
和 <img> 相比，<link> 的 fetchpriority 更容易踩哪些坑？
关键差异在解析时机与资源绑定方式：
-
<img src>的fetchpriority在 HTML 解析时立即触发预加载扫描；而<link rel="stylesheet">的优先级提示可能被 CSS 解析器延迟读取 - 若
href是 JS 动态拼接（哪怕写在 HTML 里，但含data-占位符且被 JS 替换），该属性视为无效 -
<link>不支持loading属性，所以无法用loading="lazy" fetchpriority="low"做双重保险
验证它是否起作用的唯一可靠方式
打开 Chrome DevTools → Network 面板 → 刷新页面 → 右键表头勾选 Priority 列：
- 若仍显示
Medium，大概率不是写错了，而是信号被覆盖或忽略 - 常见原因包括：资源已缓存、页面在后台标签页中、
fetchpriority与loading="lazy"共存（虽不适用 link，但开发者常误套用）、或浏览器版本不达标 - Safari / Firefox 的 Network 面板不显示
Priority列——它们根本没实现该机制，谈不上验证
真正影响 <link> 加载顺序的，仍是 rel="preload"、HTML 位置、HTTP/2 服务器推送等更底层手段；fetchpriority 对 <link> 来说，目前只是一个窄口径、易被忽略的提示信号，不是调度开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
