fetchpriority="high"仅在Chromium 112+/Safari 17.2+中生效，需同时满足：src静态存在、loading="eager"、未被preload声明、参与LCP且带width/height，否则被忽略或降级。
fetchpriority="high"什么时候真正起作用
它只在 Chromium 112+（Chrome/Edge 101+）和 Safari 17.2+ 中被读取，Firefox 完全忽略——不是报错，是静默跳过。而且它不是“设了就插队”，而是仅当同时满足以下条件时，才可能被调度器采纳：
-
src必须在 HTML 源码中静态存在，不能是data-src或 JS 后续赋值 - 必须搭配
loading="eager"；loading="lazy"或未声明（等同于auto）会直接覆盖为 Low - 不能已被
<link rel="preload" as="image">声明——preload 已锁定 Highest，fetchpriority变成冗余 - 图片需在首屏、参与 LCP 判定，且最好没有
width/height导致布局延迟（此时浏览器更倾向提权）
为什么Network面板里Priority还是Medium
这不是代码写错了，而是信号被更高优先级逻辑拦截或未触发。打开 Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，若仍显示 Medium 或 Low，常见原因有：
- 资源已缓存命中：不走网络调度，
Priority恒为Medium，属正常现象 -
loading="lazy"和fetchpriority="high"共存：Chrome 强制降级为Low，lazy逻辑优先级更高 - 页面在后台标签页中加载：Chromium 主动压低所有资源优先级，
high提示被静默忽略 -
src是空字符串、data-src或 JS 动态注入：预扫描器根本没看到资源，属性无效
哪些地方加了fetchpriority也白加
该属性支持范围极窄，很多常见写法实际不起作用，还容易误导判断：
-
<picture>或<source>上写fetchpriority：只对最外层<img>生效，内部节点全被跳过 -
<link rel="stylesheet">或<script src="app.js">上加该属性：Chromium 和 Safari 均不解析，静默丢弃 - JS 动态创建的
<img>，再用element.fetchPriority = "high"赋值：该属性只在 HTML 解析阶段读取一次，运行时修改无效 - CSS
background-image：完全不在 HTML 解析器资源发现路径中，fetchpriority对其无任何影响
正确写法和配套必须项
想让 fetchpriority="high" 有机会生效，必须和几个硬性 HTML 属性协同，缺一不可：
立即学习“前端免费学习笔记（深入）”；
- 必须写在原生
<img>标签上，且src是服务端直出的真实 URL - 必须显式声明
loading="eager"；省略或写成loading="auto"等同于 lazy，会覆盖 high - 必须设置
width和heightHTML 属性（不是 CSS），否则布局计算延迟 → 触发 CLS → LCP 判定推迟 - 同一页面最多用 2–3 处；超过会稀释效果，浏览器可能统一归入 High 队列，反而削弱关键图权重
典型有效示例：<img src="/hero.webp" fetchpriority="high" loading="eager" width="1200" height="630" alt="首页主图">
最容易被忽略的是：这个属性只在 HTML 解析阶段生效，DOM 构建完成后，再补 src 或改 fetchPriority，调度器早已完成决策。
