<link rel="preload" as="image">是唯一能抢时间的硬预加载方式，必须写在<head>中、as="image"不可省略、href需为静态根相对或绝对路径，且须与<img src>完全一致；fetchpriority="high"仅在Chrome 109+对<img>生效，旧版忽略，不推荐依赖。
预加载图片的优先级不能靠“设置”来强行拔高，而是通过选择正确的机制、满足生效条件、避开常见拦截逻辑来让浏览器真正把它当关键资源处理。
用 <link rel="preload"> 是唯一能抢时间的硬预加载
这是目前最可靠、最早触发、Lighthouse 能识别的方式，适用于你确定某张图会在首屏或交互初期立刻渲染的场景（比如 banner、logo、登录主图）。
-
as="image"必须写，缺了浏览器会当普通 fetch 处理，失去图片专用缓存和解码策略 - 路径必须是静态且准确：推荐用根相对路径（如
/assets/hero.webp）或绝对 URL；别写./images/hero.jpg，HTML 位置一变就 404 -
fetchpriority="high"在 Chrome 109+ 有效，能抬高请求优先级；旧版忽略无副作用，但不建议依赖它作为主要手段 - 别和
loading="lazy"同时用——逻辑冲突，Chrome 可能直接忽略preload - 不能在
href里写模板变量，比如"/assets/${name}.webp"会被当字面量请求，大概率 404
fetchpriority="high" 只对 <img> 生效，且条件苛刻
它不是开关，只是给 Chromium/Safari 的一个提示，能否被采纳取决于多个硬性条件。
- 只对
<img>和<iframe>有效；<picture>、背景图、JS 创建的img全部无效 - 必须是 Chromium 112+ 或 Safari 17.2+；Firefox 完全忽略，且不报错、不降级——它只是安静消失
-
src必须在 HTML 源码中静态存在，不能是空值、data-src或 JS 后续赋值 - 不能和
loading="lazy"共存，否则 Chrome 强制降级为 Low，lazy逻辑优先级更高 - 如果这张图已经被
<link rel="preload" as="image">声明过，fetchpriority就失效——preload 本身已锁定 Highest
别误用 loading 属性当优先级开关
loading 只控制“何时发起请求”，不控制“请求发出后的调度优先级”。它只有两个合法值：eager（默认）和 lazy，没有 high、low 或数字。
立即学习“前端免费学习笔记（深入）”；
-
<img loading="eager">：HTML 解析时即发起请求，适合首屏图；不写该属性等价于eager -
<img loading="lazy">：仅当进入视口（或即将进入）才发请求，适合列表、画廊等非首屏内容 -
<img loading="1">或<img loading="priority-high">不会报错，但被浏览器忽略，退化为eager - 强行对高度未固定的响应式图片加
loading="lazy"，可能引发布局抖动（FOUC），尤其没设width/height或aspect-ratio时
验证是否真生效，得看 Chrome DevTools Network 面板
别只看加载时间快不快，重点看 Priority 列是否真的变了。测试前务必禁用缓存，并在前台标签页刷新。
- 右键 Network 表头 → 勾选
Priority -
<link rel="preload" as="image">应显示为Highest -
<img src="..." fetchpriority="high">在满足条件时应显示为High或Highest（若没 preload 过） - 如果仍是
Medium，大概率是：没设loading="eager"、src动态注入、用了loading="lazy"、或浏览器根本不支持该属性 - 注意：Safari/Firefox 中
fetchpriority不会出现在 Priority 列，但也不会报错——你根本看不到它有没有起作用
最容易被忽略的一点是：fetchpriority 和 preload 都无法绕过浏览器对后台标签页的整体降级策略。如果你在新标签页中打开页面再切回来，所有这些提示都可能被静默弱化。真要保首屏体验，得把关键图放进 <head> 的 preload 里，而不是指望运行时靠 JS 或属性补救。
