fetchpriority是HTML <img> 和 <iframe> 的属性，用于提示浏览器资源下载优先级而非强制插队；仅在Chromium 112+/Safari 17.2+中生效，需src非空、搭配loading="eager"、无preload、非缓存且非后台标签页才可能起效。
fetchpriority 是什么，什么时候该用
它是个 HTML <img> 属性，用来告诉浏览器这张图的加载优先级——不是“要不要加载”，而是“跟其他资源比，它该多早开始下载”。只对 <img> 和 <iframe> 有效，且仅在资源发起网络请求前起作用（比如懒加载的图，loading="lazy" 时设 fetchpriority 没效果）。
典型适用场景：首屏关键图（如 banner、logo）、用户立即可见的主图；不适用：折叠区、display: none 的图、JS 动态插入的图（除非插入时已带属性）。
可选值只有 high / low / auto，区别在哪
auto 是默认值，浏览器按自身启发式规则判断（通常基于位置、尺寸、是否在视口内）；high 会让浏览器尽可能提前发起请求（可能抢占 CSS/JS 的带宽）；low 则会主动延后，常用于非首屏或次要装饰图。
-
fetchpriority="high"对首屏大图有效，但别滥用——连续多个high会抵消效果，浏览器仍会按内部队列调度 -
fetchpriority="low"不等于“不加载”，只是降低初始请求优先级；如果图在首屏，仍可能被提升（浏览器有兜底逻辑） - 没设该属性时，等价于
fetchpriority="auto"，不要以为不写就等于 low
和 loading、decoding、fetching 等属性怎么共存
它和 loading、decoding、fetching 是正交的，互不覆盖。但组合不当容易出意料行为：
立即学习“前端免费学习笔记（深入）”；
-
loading="lazy"+fetchpriority="high"：无效。lazy会延迟触发 fetch，此时fetchpriority已无意义 -
decoding="async"影响解码时机，不影响下载优先级；fetchpriority只管下载阶段 -
fetching="eager"（已废弃）和fetchpriority冲突，现在应统一用fetchpriority+loading="eager" - CDN 或代理若改写响应头（如加
Cache-Control），不影响fetchpriority生效，它只作用于请求发起阶段
实际调试怎么看它有没有生效
Chrome DevTools 的 Network 面板里，选中图片请求 → 查看 Headers 标签页 → 找 Priority 字段：Highest/High/Medium/Low 是浏览器最终执行的优先级（注意不是直接映射 high→Highest，受页面整体资源竞争影响）。
常见失效情况：
- 图片 URL 是 data URL 或 blob URL：不走网络请求，
fetchpriority被忽略 - 服务端返回 304（Not Modified）：复用缓存，不触发新优先级判断
- 使用了
srcset但未指定sizes：浏览器无法预估渲染尺寸，可能降级为auto行为 - 同一域名下并发连接数达上限：即使标了
high，也得排队
真正起效的前提很简单：图必须是普通 HTTP(S) 请求、在 HTML 解析早期就被发现、且没被其他机制（如 lazy、JS 注入）拦截。
