fetchpriority仅在html解析阶段读取一次，只对和生效，且需src/srcdoc非空；仅chromium 119+（chrome/edge/opera）和safari 17.2+（部分支持）识别，firefox完全忽略；必须搭配loading="eager"、无preload、非缓存、非后台标签页等条件才可能生效。
fetchpriority 不是加载阶段的“加速开关”，它只在 HTML 解析阶段被读取一次，且仅对 <img> 和 <iframe></iframe> 生效；设晚了、加错标签、或浏览器不支持，信号就彻底丢失。
哪些元素和浏览器能真正读取 fetchpriority
只有 Chromium 119+（Chrome、Edge 101+、Opera 新版）和 Safari 17.2+（仅部分支持 <img>）会解析该属性；Firefox 完全忽略。生效前提非常严格：
-
<img>或<iframe></iframe>标签必须在 HTML 源码中直接写出，不能由 JS 动态插入 -
src（或srcdoc）属性必须存在且非空字符串，例如src="hero.jpg"可行，src=""或src="data:image/png,..."不触发调度 -
<link rel="stylesheet">在 Chromium 112+ 和 Safari 17.2+ 中有极弱支持，但效果不稳定；<script></script>、<link rel="preload">、<video></video>上加该属性——浏览器静默丢弃，不报错也不生效
fetchpriority="high" 为什么经常没反应
它不是强制插队指令，而是提示信号；是否被采纳取决于多个并行条件是否同时满足：
- 必须搭配
loading="eager"：若写了loading="lazy"，Chrome 会直接无视fetchpriority="high"并强制降为 Low - 不能与
<link rel="preload">共存：preload 已锁定 Highest 优先级，再设fetchpriority属于冗余操作 - 资源需参与首屏布局：比如 LCP 候选图、轮播第一帧；一张放在
<footer></footer>里的图即使设 high，也可能因未进入预加载扫描范围而被延迟 - 页面不能处于后台标签页：此时所有资源优先级都会被系统性压低，high 提示无效
怎么验证 fetchpriority 是否真起作用
唯一可靠方式是看 Chrome DevTools 的 Network 面板内部调度结果，而非时间戳或视觉表现：
- 打开 Chrome DevTools → Network 面板 → 刷新页面 → 右键表头 → 勾选
Priority列 -
fetchpriority="high"正常应显示为Highest或High（若无 preload 覆盖）；仍显示Medium，大概率是信号被覆盖或未触发，不是写法错误 -
fetchpriority="low"多数显示为Low或Lowest，但若资源已缓存命中，Priority 显示Medium是正常现象，不代表失效 - Safari / Firefox 的 Network 面板不显示
Priority列——它们根本不实现该机制，无法验证
最容易被忽略的点是：这个属性只在 HTML 解析阶段生效，一旦 DOM 构建完成，再通过 JS 修改 element.fetchPriority 或动态补全 src，调度器早已完成决策，后续任何操作都无效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
