safari 16.4（2023年3月发布）是首个支持fetchpriority="high"的稳定版本，此前所有safari版本均忽略该属性；chrome和firefox早在2022年中已支持。
fetchpriority="high"在Safari 16.4之前确实不支持
Safari 直到版本 16.4（2023 年 3 月发布）才开始实现 fetchpriority 属性。此前所有 Safari 版本（包括 16.3、16.2 等）会完全忽略该属性，既不报错，也不提升加载优先级。
-
fetchpriority="high"在 Safari - Chrome 和 Firefox 早在 2022 年中就已支持该属性，因此跨浏览器测试时容易误判为“生效”
- Safari 16.4 是首个支持该特性的稳定版，且仅限 macOS Monterey 及更新系统；iOS/iPadOS 16.4 同步支持
如何检测 Safari 是否真正执行了 fetchpriority？
不能只看 HTML 里有没有写，得验证实际网络请求的优先级：
- 打开 Safari 开发者工具 → Network 面板 → 刷新页面 → 找到目标
<img>请求 - 查看该请求的 Priority 列：若显示
High（而非Low或Medium），说明生效 - 若 Priority 显示为空或仍是
Low，大概率是 Safari 版本不足，或该资源被其他逻辑覆盖（如被loading="lazy"抑制）
注意：loading="lazy" 与 fetchpriority="high" 共存时，Safari 16.4+ 会以 fetchpriority 为准，但旧版 Safari 会直接按 lazy 规则延迟加载——此时 fetchpriority 彻底失效。
替代方案：当需要兼容 Safari
没有直接等价的 DOM 属性可降级，但可通过组合手段逼近效果：
- 对关键图片（如 LCP 候选）使用
<link rel="preload">，并显式指定as="image"和fetchpriority="high"（后者虽被忽略，但preload本身在 Safari 11+ 就受支持） - 示例：
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
- 避免对同一资源既
preload又在<img>中重复声明src，否则可能触发双下载 - 若用 JavaScript 动态插入图片，可在
document.readyState === "interactive"阶段提前new Image().src = ...，绕过默认懒加载逻辑
最容易被忽略的细节：fetchpriority 不是万能加速开关
fetchpriority="high" 只影响「请求发起时机」，不改变以下事实：
- 图片仍需解码、布局、绘制，这些阶段不受该属性控制
- 若图片 URL 返回 404 或响应头含
Cache-Control: no-store，高优先级也救不了首屏体验 - 在慢网（如 3G）下，高优先级可能抢占带宽，反而拖慢 CSS/JS 加载，导致白屏延长
- Safari 16.4+ 的
fetchpriority="high"对<img>生效，但对<picture></picture>内部的<source></source>不起作用（需对每个<source></source>单独加）
