fetchpriority="high"仅是向chromium调度器发出高优先级提示，影响请求发起时机和带宽分配，不强制插队；仅对src存在的和生效，chrome devtools中通过priority列验证，safari/firefox不支持。
fetchpriority="high" 不等于“立刻加载”，它只影响请求发起时机和带宽分配
设置 fetchpriority="high" 并不会强制浏览器跳过队列、插队下载，而是向 Chromium 的资源调度器发出一个高权重提示：在空闲连接可用、尚未触发懒加载限制、且资源已进入预加载扫描范围时，更倾向提前发起该 <img> 请求，并分配更多初始带宽。但它无法突破以下限制：
- 资源尚未被 HTML 解析器发现（比如 JS 动态插入后才加该属性）→ 完全无效
- 同时设置了
loading="lazy"→ Chrome 直接忽略fetchpriority，降级为auto - 图片位于折叠区、视口外、或 DOM 插入过晚 → 即使设为
high，也可能被延迟到视口接近时才触发 - 同域并发请求数已达上限 → 仍需排队，只是排在队列靠前位置
哪些标签能用 fetchpriority？别往 或 <script> 上硬加</script>
fetchpriority 当前仅对 <img> 和 <iframe></iframe> 生效，且必须满足两个前提：src（或 srcdoc）属性存在且非空。其他常见误用包括：
- 给
<link rel="stylesheet">加fetchpriority="high"→ 浏览器直接忽略，CSS 优先级由是否阻塞渲染决定 - 给
<script src="app.js"></script>加该属性 → Chromium 112+ 起已明确不支持，属性被静默丢弃 - 在
<video></video>或<audio></audio>上使用 → 无效果，这些元素走媒体加载路径，不参与 fetch priority 队列 - 写成
<img fetchpriority>（无值）或fetchpriority="urgent"（非法值）→ 属性不被识别，回退为auto
Chrome DevTools 里怎么看它有没有起作用
不能只看 Network 面板里“Start Time”早不早，得查浏览器内部调度结果：
- 打开 Chrome DevTools → Network 面板 → 刷新页面
- 右键表头 → 勾选 Priority 列
- 定位目标
<img>请求，观察其 Priority 值：
–fetchpriority="high"通常显示为Highest或High（若没被preload覆盖）
–fetchpriority="low"多数为Low或Lowest
– 若仍显示Medium，说明提示未被采纳（常见于缓存命中、后台标签页、或与loading="lazy"共存） - 注意：Safari / Firefox 的 Network 面板不显示 Priority 列，也无法验证 —— 它们根本没实现该机制
和 loading、decoding、preload 混用时的优先级覆盖关系
多个加载控制属性共存时，不是简单叠加，而是存在明确的覆盖层级：
-
<link rel="preload">优先级最高 → 一旦用了 preload，fetchpriority就失去意义 -
loading="lazy"逻辑优先级高于fetchpriority→ 同时出现，fetchpriority="high"被无视 -
decoding="async"只影响解码阶段，不影响下载顺序，但和fetchpriority="high"搭配可形成“快下 + 快解”闭环 - 服务端返回
Cache-Control: max-age=3600时，fetchpriority对已缓存资源无任何影响 —— 它只作用于网络请求阶段
真正容易被忽略的是：这个属性在 SSR 渲染时就得决策好，JS 运行时补加无效；而且它只在 Chromium 系列生效，Safari/Firefox 用户完全感知不到——别把它当跨浏览器性能银弹。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
