fetchpriority仅对<img>和<iframe>生效，需src/srcdoc非空，且仅在Chrome 119+、Edge 101+、Opera新版及Safari 17.2+（部分支持）中可用，Firefox完全不支持；它仅为提示信号，非强制插队，生效需满足无preload、无lazy、非缓存、非后台标签页等条件。
fetchpriority 不是强制插队开关，它只在特定标签、特定浏览器、特定时机下向 Chromium 调度器发一个提示信号；加了不一定生效，乱加反而稀释真正关键资源的权重。
哪些标签和浏览器支持 fetchpriority
它目前仅对 <img> 和 <iframe> 生效，且必须满足：src（或 srcdoc）属性存在且非空。其他全忽略：
-
<link rel="stylesheet">上加该属性——Chromium 112+ 和 Safari 17.2+ 有部分支持，但效果不稳定；Firefox 完全忽略 -
<script src="app.js">、<video>、<link rel="preload">上写fetchpriority——浏览器静默丢弃，不报错也不调度 - JS 动态创建的
<img>，再用element.fetchPriority = "high"赋值——无效，该属性只在 HTML 解析阶段读取一次 - Chrome 119+、Edge 101+、Opera 新版完全支持；Safari 17.2+ 仅部分支持
<img>；Firefox 完全不识别
fetchpriority="high" 真正起作用的条件
它不是“设了就提前”，而是需要同时避开多个覆盖逻辑才能被采纳：
- 资源必须有明确
src，且不能是空字符串或靠 JS 后续注入 - 必须搭配
loading="eager"，否则loading="lazy"会直接覆盖并降级为Low - 不能已被
<link rel="preload">提前声明——preload 已锁定Highest，fetchpriority失去意义 - 图片需在首屏、参与 LCP、无
width/height导致无法早期布局时，提示才最可能被采纳 - 页面不能处于后台标签页中——此时所有资源优先级都会被主动压低
示例有效写法：<img src="hero.jpg" fetchpriority="high" loading="eager" width="1200" height="600" alt="首页主图">
立即学习“前端免费学习笔记（深入）”；
为什么 Network 面板里 Priority 没变
这是最常被误判的点：不显示 Highest 或 Lowest ≠ 属性写错了，大概率是信号被更高优先级逻辑覆盖或未触发调度：
- 资源已缓存命中——浏览器不走网络调度，
Priority显示Medium是正常现象 - 同时用了
loading="lazy"且图片未进入视口——Chrome 强制将其降为Low，fetchpriority="high"被无视 - 页面刚加载完就刷新 DevTools，没勾选
Preserve log——初始调度决策可能未被捕获 - 目标请求在后台标签页中发起——浏览器统一压低优先级，
high提示无效
验证方式唯一可靠路径：Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列 → 找到对应 <img> 请求，看其值是否变化。
fetchpriority="low" 不是降级，是主动让权
它的作用不是把资源塞进最低队列，而是显式放弃带宽竞争权，把连接和解码资源留给更紧急的任务：
- 适合页面底部社交图标、
<details>折叠区内的图、纯装饰性小图 - 可与
decoding="async"组合：前者管“多快下载”，后者管“解码是否卡主线程” - 不要给已用
loading="lazy"的图片再加fetchpriority="low"——lazy 本身已触发低优先级策略，叠加无收益，纯属冗余 - 注意 Chrome 某些版本会把
low自动降回auto，别依赖它稳稳生效
真正起作用的点往往藏在细节里：比如同一张图既没 preload 又没 loading，这时 fetchpriority="high" 才最可能被采纳；而一旦混用多个控制手段，优先级逻辑就容易互相打架，反而不如只用一种来得稳。
