fetchpriority 属性是声明资源优先级最有效方式，仅在html解析阶段生效，需在源码中为关键资源设high，禁用lazy冲突，不支持js请求和旧浏览器需回退preload。
直接用 fetchpriority 属性在 HTML 中声明资源优先级，是最有效、最稳定的方式。它不是 JavaScript 运行时的动态干预，而是浏览器解析 HTML 阶段就生效的调度信号——这点必须明确。所谓“动态”，实际体现在根据页面状态、用户行为或设备条件，在服务端渲染（SSR）或构建时生成不同优先级的 HTML 标签，而非在 JS 中实时改写 fetchpriority 值（该属性不可通过 JS 动态修改并触发重调度）。
关键资源必须在 HTML 初始解析时标记高优先级
首屏 CSS、LCP 图片、核心字体等资源，若未在 HTML 源码中第一时间带 fetchpriority="high"，浏览器会按默认启发式规则排队，很可能错过首屏渲染窗口。延迟到 JS 执行后再插入带 high 优先级的 <img>，已失去意义——请求早已发起或被降级。
-
<link rel="stylesheet" href="critical.css" fetchpriority="high">—— 强制阻塞渲染的样式尽早下载 -
<img src="hero.jpg" fetchpriority="high" alt="">—— 首屏大图必须抢在其他图片前触发请求 - 轮播图中仅第一张图加
fetchpriority="high"，其余用"low"或不设（默认为 low）
避免与 lazy/loading 冲突导致优先级失效
fetchpriority 不是绝对指令，会被更高层加载策略覆盖。最常见失效场景是和 loading="lazy" 同时使用：即使写了 fetchpriority="high"，只要图片尚未进入视口，Chrome 仍将其降级为 low。
- 首屏内资源禁用
loading="lazy"，否则fetchpriority形同虚设 - 头像、评论区图片等离屏资源可双降级：
fetchpriority="low" loading="lazy" -
decoding="async"同样会压制fetchpriority，非必要不混用
JS 发起的请求无法用 fetchpriority，需换思路
fetchpriority 只作用于 HTML 解析器发现的资源（<link>、<img src>、<script src></script> 等），对 fetch() 或 XMLHttpRequest 完全无效。
- 如需提升 JS 请求优先级，仅 Chromium 支持手动加请求头：
fetch('/api/data', { headers: { 'Importance': 'high' } }) - 注意：
Importance请求头非标准，Firefox/Safari 忽略；服务端也无法据此调整 TCP 队列或 CDN 行为，纯属客户端提示 - 更可靠的做法仍是前置化：把关键数据接口响应内联进 HTML，或通过 SSR 直接注入，绕过 JS 请求
不支持 fetchpriority 的浏览器必须回退到 preload
当前兼容性为 Chrome 101+、Edge 101+、Safari 17.2+。旧版 Safari 或 Firefox 用户占比较高的项目，需用 <link rel="preload"> 回退。
-
<link rel="preload" href="critical.css" as="style" fetchpriority="high">—— 新浏览器走 fetchpriority，老浏览器 fallback 到 preload 的高优先级 - 不要对
<script type="module"></script>或async脚本加fetchpriority：浏览器已将其设为 low，强行设 high 可能干扰预加载逻辑 - preload 本身是强制指令，慎用，避免重复加载（如同时存在
<link rel="stylesheet">和<link rel="preload">）
