截至2024年中，fetchpriority仅支持chrome 109+、edge 109+、opera 95+等chromium内核浏览器，firefox和safari完全不识别，且该属性仅适用于html的和元素，不影响资源是否加载，只调整加载优先级。
fetchpriority 属性目前支持哪些浏览器
截至 2024 年中，fetchpriority 仅在基于 Chromium 的浏览器中可用（Chrome 109+、Edge 109+、Opera 95+），Firefox 和 Safari 完全不识别该属性，也不会触发任何优先级调整行为。它不是 CSS 或 JS API，而是 HTML <img> 和 <iframe></iframe> 元素的原生布尔属性，浏览器忽略未知属性是标准行为，所以 Safari/Firefox 下写上 fetchpriority="high" 不会报错，但也没效果。
常见误判点：fetchpriority 不是 loading 属性的替代品，也不影响资源是否加载，只影响加载队列中的调度顺序。
什么时候该用 fetchpriority="high" 而不是 loading="eager"
loading="eager" 强制取消懒加载，但不改变资源在网络请求队列里的优先级；fetchpriority="high" 则向浏览器明确声明“这个资源比默认的 auto 更重要”，可能提前发起请求、分配更高带宽权重。两者可共存，例如首屏大图：
@@##@@
典型适用场景包括：
- 首屏关键图像（非背景图）、主视觉
<iframe></iframe>（如嵌入的登录弹窗） - 用户交互前已确定要加载的资源（比如点击按钮后立即展示的模态图）
- 与
decoding="async"配合时，避免解码阻塞高优图像渲染
注意：fetchpriority="low" 在 Chrome 中实际效果不稳定，部分版本下会被降级为 auto，不建议依赖。
fetchpriority 和 resource hints（如 preload）冲突吗
不冲突，但有隐式覆盖关系。<link rel="preload"> 声明的资源会获得最高网络优先级（Highest），此时再给对应 <img src="hero.jpg" fetchpriority="high" loading="eager"> 加 fetchpriority="high" 不会进一步提升——浏览器已按 preload 规则处理了。反过来，如果用了 fetchpriority="high" 却没做 preload，它无法突破浏览器对同域并发请求数、HTTP/2 流优先级等底层限制。
实操建议：
- 对极关键资源（如首屏字体、核心 JS），仍优先用
<link rel="preload">，更可控 -
fetchpriority更适合动态插入的元素或无法预知 URL 的场景（如 CMS 渲染的图片） - 不要在已
preload的资源上重复加fetchpriority，无增益且增加 HTML 体积
服务端或构建工具里怎么安全启用 fetchpriority
不能全局硬编码，必须结合资源可见性判断。静态站点生成器（如 Hugo、Astro）可在模板中根据 frontmatter 标记注入；React/Vue 项目建议封装自定义 Image 组件，通过 props 控制：
<image src="avatar.jpg" priority="{true}"></image>
编译时需确保：
- 仅对首屏内或 viewport 立即可见的图片输出
fetchpriority="high" - 服务端渲染（SSR）时，若无法准确判断首屏范围，宁可不加，避免误导客户端调度
- Webpack/Vite 插件自动添加时，务必排除
background-image对应的<div>（它们不支持该属性） <p>最易被忽略的一点：CDN 或代理层若做了 HTML 压缩（如移除布尔属性值），可能把 <code>fetchpriority="high"简化成fetchpriority，而 Chrome 当前只识别带值的写法（fetchpriority="high"或fetchpriority="low"），空属性会被忽略。
