fetchpriority 属性仅对 有效，chrome/edge 112+ 支持，对 preload/prefetch/modulepreload 等无效；取值仅限 high/low/auto，用于调整 css 加载优先级，不改变渲染阻塞本质。
fetchpriority 属性只对 <link rel="stylesheet"> 有效
这个属性不是所有 <link> 类型都支持，目前（Chrome 112+、Edge 112+）仅对 CSS 资源起作用，<link rel="preload"> 或 <link rel="prefetch"> 加了也无效。浏览器会直接忽略——不会报错，但也不改变加载优先级。
常见误用场景：
- 给字体文件加 fetchpriority="high"（rel="preload" 场景）→ 无效果
- 给 JS 的 <link rel="modulepreload"> 加 → 同样被忽略
fetchpriority 的取值和实际行为差异
它只有三个合法值："high"、"low"、"auto"（默认）。注意："auto" 不是“自动判断”，而是“按浏览器默认规则处理”，通常等同于未声明该属性。
-
fetchpriority="high"：让 CSS 文件在 HTML 解析早期就发起请求，可能抢占其他中低优先级资源（如图片、普通 JS）的带宽 -
fetchpriority="low"：延迟 CSS 加载，适用于非首屏、可异步渲染的样式表（比如打印样式media="print"） - 没有中间档（比如没有
"medium"），也不能设为数字或布尔值
示例：
<link rel="stylesheet" href="critical.css" fetchpriority="high"><br><link rel="stylesheet" href="print.css" media="print" fetchpriority="low">
和 media、disabled、onload 的兼容性问题
如果同时用了 media（如 media="(min-width: 768px)"），fetchpriority 依然生效，但浏览器只会在媒体查询匹配时才真正下载——也就是说，优先级策略只在触发下载那一刻起作用。
容易踩的坑：
-
disabled="true"+fetchpriority="high"：样式表不会加载，优先级设置被跳过 - 动态插入
<link>（JS 创建）后补fetchpriority属性：部分浏览器不识别（尤其旧版 Chromium），必须在插入 DOM 前就设好 - 和服务端渲染（SSR）配合时，若 HTML 已输出，再通过 JS 修改
fetchpriority值，不会回溯影响网络请求队列
比 preload 更轻量，但不能替代关键资源内联
fetchpriority="high" 不等于 <link rel="preload" as="style">。前者只是调整同类型资源间的相对优先级；后者会强制提前发起请求，甚至绕过 HTML 解析顺序。
真正影响首屏性能的关键点还是：
- 首屏必需 CSS 是否足够小？大文件即使
high也会拖慢解析 - 是否仍存在阻塞渲染的外部 CSS？
fetchpriority改不了渲染阻塞本质 - HTTP/2 或 HTTP/3 环境下，优先级信号可能被服务器端调度覆盖（取决于后端配置）
所以别指望单靠这个属性解决 FOUC 或 CLS —— 它只是微调工具，不是渲染优化银弹。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
