loading="lazy" 与 fetchpriority="high" 不能共存，Chrome 会忽略后者，因语义冲突：lazy 延迟请求发起，high 则争抢带宽；仅当 loading="eager" 或未声明时，fetchpriority 才生效。
loading="lazy" 和 fetchpriority="high" 不能共存
Chrome 会直接忽略 fetchpriority="high"，只要 loading="lazy" 存在。这不是 bug，是明确的设计逻辑：lazy 表示“暂不请求”，而 high 是“请求后抢带宽”，两者语义冲突，浏览器选择优先执行 lazy 的调度决策。
常见错误现象：<img src="hero.jpg" loading="lazy" fetchpriority="high"> 在 Network 面板里 Priority 显示为 Low 或 Medium，不是写错了，而是 lazy 已强制降级整个请求队列优先级。
-
loading="lazy"触发的是“延迟发起请求”，此时资源甚至没进网络调度队列，fetchpriority根本没机会被读取 - 只有当图片已确定要加载（即
loading="eager"或未声明该属性），fetchpriority才可能参与后续带宽争抢 - Safari 对
fetchpriority支持有限，Firefox 完全忽略；但无论哪款浏览器，loading="lazy"都会覆盖或使fetchpriority失效
fetchpriority="low" 和 loading="lazy" 组合是冗余操作
加了 fetchpriority="low" 并不会让 lazy 图片“更懒”——它只是对已发起的请求做低权重提示，而 lazy 图片在进入视口前根本不会发起请求。
实际效果上，这种组合既不提升性能，也不降低带宽占用，反而容易误导维护者以为做了“双重优化”。
立即学习“前端免费学习笔记（深入）”；
- Chrome 120–123 版本中，
fetchpriority="low"在 lazy 场景下常显示为Medium，说明信号未被采纳 - 如果图片被 UA 识别为 LCP 候选（比如首屏内、尺寸大、无宽高），
fetchpriority="low"会被自动覆盖为auto - 真正需要降权的是非首屏但已 eager 加载的图（如轮播第二张），这时才适合
fetchpriority="low"+loading="eager"
什么时候该用 fetchpriority="high"
只对静态 HTML 中、src 已写死、且必须立即加载的关键图有效，典型场景是首屏 LCP 图，且它因缺失 width/height 导致布局计算延迟。
必须同时满足：loading="eager"（或不写）、src 非空、浏览器 ≥ Chromium 119、未被 <link rel="preload"> 覆盖。
- 有效写法：
<img src="hero.jpg" fetchpriority="high" loading="eager" width="1200" height="600"> - 无效写法：
<img loading="lazy" fetchpriority="high">——data-src不触发解析期调度，属性静默失效 - 无效写法：
<img src="">后用 JS 赋值 ——fetchpriority只在 HTML 解析阶段读取一次，之后赋值无效
验证 fetchpriority 是否生效的唯一可靠方式
别看加载时间，也别信控制台警告，只看 Chrome DevTools → Network 面板 → 右键表头勾选 Priority 列，找到对应 <img> 请求的值。
前提是：禁用缓存（勾选 Disable cache）、在前台标签页刷新、确保图片未被 preload 或 prefetch 提前锁定。
-
fetchpriority="high"应显示为Highest（若同时有<link rel="preload">）或High（纯 fetchpriority） -
fetchpriority="low"多数显示为Low或Lowest；若仍是Medium，说明浏览器未采纳该提示 - 缓存命中时 Priority 恒为
Medium，这是正常行为，不代表fetchpriority失效
fetchpriority 在 Safari 和 Firefox 中完全静默失效，不报错、不降级、不 fallback —— 它只是不存在。如果你靠它保障关键图加载节奏，必须同步提供 <link rel="preload"> 作为兜底。 
